CA Security Management on Converging Physical and Logical Event Data

| 0 Comments | 0 TrackBacks

Page:   1   2  Next  »

Using Physical Location and Logical Data to Create Proactive Rules-Based Alarms and Alerts

What's the best connection point between logical security events and physical security events if you want to correlate the two? That's what we asked Dave Hansen, corporate senior vice president and general manager (pictured) for CA Security Management.

HansenCAFinal.jpgAccording to the Gartner Group's Magic Quadrant 2009 for Security Information/Event Management (SIM/SIEM), CA Security Management is challenging industry leaders ArcSight and Cisco Systems in that space. Hansen talked about sensible connection points--not just for real-time policy-based alerts security, but for adding value to enterprise applications.

What follows is Part One of the transcript of our conversation, abridged and edited for clarity. Catch more of Hansen's thoughts on natural SIEM and PSIM connections and more tomorrow.

Dave Hansen: It's not that big of a challenge building a connector to talk to a physical access system because those things are just massive logging engines. They are logging very transactional data. A badge gets swiped, a gate opens and closes, those are all the logs that go in. So it's actually not technically very difficult to take the feeds from those systems into a security information management system.

[A badge system] is a powerful tool to determine if people are following corporate policy and guidelines. Leveraging some of that information into your IT systems is just a great opportunity. We're doing a ton of work on this right now to be able to show some of the use cases and the value of doing that.

Sharon J. Watson:
So from your perspective, Dave, this would be a largely IT driven project?

DH: It's very joint. Because we are doing a lot of work on this, the two people who run the physical security and logical security [for CA] have been in my office a lot lately. Traditionally those two guys here work together on a lot of forensic stuff. What I want to see is much more proactive, policy-based alarming. That's the thing I think would just be fantastic.

We want to try to prevent things from happening. We don't want to fire an employee for doing something bad if we can stop it, because a lot of misuse sometimes happens by mistake. We look at that all the way to the data loss prevention side. We want to prevent these things from happening before the newspaper is reporting company XYZ lost 25,000 credit card numbers or health insurance numbers or whatever.

Today everyone uses those systems very, very forensically--when they're working together. They're obviously used for their purposes every day but when [physical and logical security professionals] work together, ninety percent of the time I'd say they're trying to sort through something that happened and why.

[Proactive alerts are] absolutely doable with the technical knowledge available today. The tricky part becomes normalizing the data between the systems so that they become easier to look at because it's not the traditional data elements that we've been pulling into these systems in the past. Then you can run policy against that data.

SJW: Can we talk about that in a little more detail?

DH: These systems kick out records. That's all they are. That's like a firewall will kick out a record every millisecond or second depending on what you have the filtering set at. They all have proprietary information. The one thing the industry's never been great at is having one very standard messaging profile or protocol for these types of things. So what you have to do is be able to categorize the different things, such as what is the event, what is the description of the event, who did it or what did it.

Then [you need to] be able to compare that so you can put it in one big database engine or have some way of being able to access the data quickly...then being able to look through that and see how that stuff compares.

One of the biggest things is the actual timestamp on it. So if something is happening in a certain period, you can then say, 'Well, it could be that these things are related' and kick that up as a flag saying 'A thousand things just happened in the last five minutes revolving around either this device or this identity' -- and that's where we've got to go. The red flag would come up and then you have the ability to do something: you're going to alert someone, you're going to alarm something, shut something off. You want to take some kind of action at that point.

SJW: How much of that winds up being custom scripting or connections?  When I was looking at your website, I did the demo with your host-based intrusion detection system. I noticed you could create a policy: it was very point and click, very simple to use. If a user was copying or accessing an infected object on a client, it could deny them network access for a set period. Wouldn't it be cool if you could take that a step further and tie that policy to their badge, find out where they are, did they actually even swipe in that day? But that was a very menu-driven system, and some of what you're saying sounds like it might involve more. I just wonder how canned you can get [the policy creation] versus custom.

DH: You can make it a lot more canned. We've been looking at this over the last five years, and in the past it was so customized, it was virtually impossible. I think we could get to that level. Now the product you were looking at was part of the integrated Threat Manager, which is really driven from an anti-virus point of view. A user has somehow infected their machine. That's a great example of a use case. You want to deactivate that user, and you could potentially deactivate their badge if you thought that person was a bad person.

Normally what would happen if someone got a virus is probably that they're a stupid person, not a bad person. They are not going to infect themselves, right? So it's not that they're trying to propagate a virus. You want to get them off the network but you might not want to throw them out of the building just yet. I think you might find that hard to do with [the host-based intrusion detection tool] because you're so focused at the client side and looking at malware and how that can propagate through and generally are not tied back to a lot of identity-based systems.

Page:   1   2  Next  »

Using Physical Location and Logical Data to Create Proactive Rules-Based Alarms and Alerts

What's the best connection point between logical security events and physical security events if you want to correlate the two? That's what we asked Dave Hansen, corporate senior vice president and general manager (pictured) for CA Security Management.

HansenCAFinal.jpgAccording to the Gartner Group's Magic Quadrant 2009 for Security Information/Event Management (SIM/SIEM), CA Security Management is challenging industry leaders ArcSight and Cisco Systems in that space. Hansen talked about sensible connection points--not just for real-time policy-based alerts security, but for adding value to enterprise applications.

What follows is Part One of the transcript of our conversation, abridged and edited for clarity. Catch more of Hansen's thoughts on natural SIEM and PSIM connections and more tomorrow.

Dave Hansen: It's not that big of a challenge building a connector to talk to a physical access system because those things are just massive logging engines. They are logging very transactional data. A badge gets swiped, a gate opens and closes, those are all the logs that go in. So it's actually not technically very difficult to take the feeds from those systems into a security information management system.

[A badge system] is a powerful tool to determine if people are following corporate policy and guidelines. Leveraging some of that information into your IT systems is just a great opportunity. We're doing a ton of work on this right now to be able to show some of the use cases and the value of doing that.

Sharon J. Watson:
So from your perspective, Dave, this would be a largely IT driven project?

DH: It's very joint. Because we are doing a lot of work on this, the two people who run the physical security and logical security [for CA] have been in my office a lot lately. Traditionally those two guys here work together on a lot of forensic stuff. What I want to see is much more proactive, policy-based alarming. That's the thing I think would just be fantastic.

We want to try to prevent things from happening. We don't want to fire an employee for doing something bad if we can stop it, because a lot of misuse sometimes happens by mistake. We look at that all the way to the data loss prevention side. We want to prevent these things from happening before the newspaper is reporting company XYZ lost 25,000 credit card numbers or health insurance numbers or whatever.

Today everyone uses those systems very, very forensically--when they're working together. They're obviously used for their purposes every day but when [physical and logical security professionals] work together, ninety percent of the time I'd say they're trying to sort through something that happened and why.

[Proactive alerts are] absolutely doable with the technical knowledge available today. The tricky part becomes normalizing the data between the systems so that they become easier to look at because it's not the traditional data elements that we've been pulling into these systems in the past. Then you can run policy against that data.

SJW: Can we talk about that in a little more detail?

DH: These systems kick out records. That's all they are. That's like a firewall will kick out a record every millisecond or second depending on what you have the filtering set at. They all have proprietary information. The one thing the industry's never been great at is having one very standard messaging profile or protocol for these types of things. So what you have to do is be able to categorize the different things, such as what is the event, what is the description of the event, who did it or what did it.

Then [you need to] be able to compare that so you can put it in one big database engine or have some way of being able to access the data quickly...then being able to look through that and see how that stuff compares.

One of the biggest things is the actual timestamp on it. So if something is happening in a certain period, you can then say, 'Well, it could be that these things are related' and kick that up as a flag saying 'A thousand things just happened in the last five minutes revolving around either this device or this identity' -- and that's where we've got to go. The red flag would come up and then you have the ability to do something: you're going to alert someone, you're going to alarm something, shut something off. You want to take some kind of action at that point.

SJW: How much of that winds up being custom scripting or connections?  When I was looking at your website, I did the demo with your host-based intrusion detection system. I noticed you could create a policy: it was very point and click, very simple to use. If a user was copying or accessing an infected object on a client, it could deny them network access for a set period. Wouldn't it be cool if you could take that a step further and tie that policy to their badge, find out where they are, did they actually even swipe in that day? But that was a very menu-driven system, and some of what you're saying sounds like it might involve more. I just wonder how canned you can get [the policy creation] versus custom.

DH: You can make it a lot more canned. We've been looking at this over the last five years, and in the past it was so customized, it was virtually impossible. I think we could get to that level. Now the product you were looking at was part of the integrated Threat Manager, which is really driven from an anti-virus point of view. A user has somehow infected their machine. That's a great example of a use case. You want to deactivate that user, and you could potentially deactivate their badge if you thought that person was a bad person.

Normally what would happen if someone got a virus is probably that they're a stupid person, not a bad person. They are not going to infect themselves, right? So it's not that they're trying to propagate a virus. You want to get them off the network but you might not want to throw them out of the building just yet. I think you might find that hard to do with [the host-based intrusion detection tool] because you're so focused at the client side and looking at malware and how that can propagate through and generally are not tied back to a lot of identity-based systems.

<!--nextpage-->

What we're talking about would be using our Enterprise Log Manager, which is a relatively new product. It would get an event [from the threat system] that an employee did something bad, and...we could then correlate that with the badge system and send information to the badge system to do something.

Your head is on the right way. These are the use cases we're all brainstorming around. How do we go back and forth between these systems that have been quite divergent in the past and now can do just so much more. The place where I think we want to go is [thinking] about the location-centric data and feeding that into the role and identity as well.

Because I think a lot of people are saying well, provisioning badges and de-provisioning  badges is a critical application, and I agree. Using [the badge] as multifactor authentication, is critical, critical. Those are the base use cases we're all very focused on. But then taking the very cool data from the badging system for the physical location information of people, the ideas are flowing about what we could possibly do with that [such as] being able to look at where people are and their work habits location-wise and feed that into their role and identity to then decide what level of physical access they really need

Why actually create the risk of giving [someone] access to our offices in the U.K.? So if we look at the patterns that are happening based on certain roles and role types, we would probably get a very tight physical security policy. If you needed an exception, you could fill out a web form and go to the security department and they'd grant you access for that, no problem. But today, it's just too easy to turn on excessive physical access privileges than it is to control them by the actual usage patterns people have.

SJW: I need to be clear: Are there specific sorts of logical security tools that make the most sense to connect to physical systems? I know I had talked about the host-based intrusion detection system...and it sounded like you were not thinking about that as the kind of system you would connect through.

DH: I would [connect it] but in a different way. So the three things I would connect with: number one, the provisioning system. What I want there is to de-provision people. The provisioning is handy and it's a timesaver and a good best practice, but the de-provisioning of badge access is critical, so that's number one.

Number two is the potential of using the badge or the physical ID as part of the authentication process because people are constantly looking for multi-factor methods. At CA, we have 14,000 people running around with badges to physically get into a building, and even if they are at home, they still have their badges. We could absolutely use the technology within badges to give us the verification that person is that person. So I feel strongly about that.

Third is using the SIEM solution as the integration point for the events that are happening. So to your example of using the host-based intrusion detection system, its data would come into the log management or SIM system--that would do the correlation there. It's hard to do [alert policies] by user, by laptop, by endpoint. [So] we take those events [from anti-virus, malware, intrusion detection tools] into our Enterprise Log Manager. Then we would correlate events that are happening within that, and then we could use that to communicate that there is an issue. We could then propagate back through the system to say 'deactivate someone's physical access.'

You want to put a layer of abstraction. What you want to do is capture the event structure that is happening today, you don't want to do much custom work at [the individual tool] level, do some custom work at the event normalization at the SIEM solution. That's where you're going to catch things. That's where the excitement comes in on the proactive prevention [rather] then doing the basic forensics work.

# # #
 

No TrackBacks

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

Leave a comment