Physical/Logical Convergence via SIEM

| 0 Comments | 0 TrackBacks

Page:   1   2  Next  »

Convergence Driven by Information Security

When researching a story about how enterprises can achieve a comprehensive, correlated view of their physical and logical security, Security Squared went to a person who wrote the book on the subject. That's Colby DeRodeff, Thumbnail image for ColbyDerodeff.jpga co-author of Physical and Logical Security Convergence: Powered by Enterprise Security Management, and enterprise strategist for ArcSight, the leader in security information and event management (SIEM) tools as per the Gartner Group in June 2009.

SIEM solutions are analogous to physical security information management systems (PSIM), correlating data coming from many logical security tools, such as intrusion detection, antivirus scans, firewalls, routers, etc. In this first part of his conversation with Sharon J. Watson, DeRodeff deals with technical issues for converging physical and logical event data.

What follows is an edited transcription of our conversation, edited for clarity. Part Two will post September 1.

*********

Sharon J. Watson: What has to happen to connect and correlate data you get about logical security events and physical events so you can get a really good look at what is an imminent threat or a threat that's unfolding as well as pull trending data so you can anticipate and stop some things?

Colby DeRodeff: One of the biggest challenges that you have in trying to correlate physical security data with logical data is the disparity between how those different systems identify individuals. An example of that: at the very basic convergence level, you're trying to compare logs from a badge reader to logs from a domain controller that is allowing me to authenticate to the network. When I look at the log from a badge reader, that badge reader system usually will identify Colby as a numbered ID, like 123457. The domain controller that's doing the network authentication will identify Colby as my domain logon ID, ColbyDeRodeff or CDeRodeff, or what have you.

When I try to do a systematic comparison of those two values, they don't really match up.

So I wouldn't be able to say this ID equals Colby. One of the first places where SIEM or the ArcSight platform allows you to start doing this comparison is using a technology we call IdentityView and identity correlation. We allow you to map to a common identifier.  

For example, let's say I was collecting phone records and e-mail and physical logs and Windows event logs. All of those different log sources are going to identify me differently. What identity correlation does is tie those four different attributes back to one common identity, so I would basically be tying all of those back to Colby DeRodeff.

SJW: The one identity that it ties them back to--who defines it, where does it reside? Is that in the identity management system or Active Directory or an LDAP?

CD: Typically you're going to find that in either an identity management solution or in Active Directory. Active Directory really is an identity management solution in all senses. Organizations sometimes use other products for provisioning. Where you decide that unique ID is doesn't really matter as long as you have one source telling me this is the unique ID that you're going to use for each user.

SJW: Your platform would also tie in data from a physical system, or is it purely in the logical space?

CD: No, our product correlates pretty much anything that you want. I've worked with customers to bring in logs from video analytics systems, logs from HVAC systems, alarms from glass breaking sensors, records about who's coming in through a door or turnstile. The system doesn't really care what type of data it's correlating. Like I said, the biggest challenge is that you need to be able to tie these back to one individual. That's what we allow you to do.

There are a lot of other challenges related to convergence that are not so much technology challenges. There are also a lot of challenges with first getting people to understand why it's important. It's actually easier for someone to steal a laptop that has customer information on it than it is for someone to write a sophisticated buffer overflow or hacker exploit to get into the database that has that information. That's one example.

Another challenge is that these organizations are historically disparate: you have a physical security team and then you have a logical or network security team. A lot of times you'll find these people don't even know who the other team is or where it is in the organization. So there is very poor communication.

One thing I've also found to be a challenge is if organizations are renting or leasing space...the building security is not actually part of the company. Let's say I have floors 10 through 20. There are a lot of other companies in the building as well, the badges are issued by the building, not necessarily the company, so sometimes getting access to that data can be a challenge.

SJW: I want to take you back to the solution you outlined for me using the ArcSight platform and tying those identities together.  Is that purely forensic or does that become real time so it can contribute to monitoring events across all those systems and identify when a particular identity is doing something that is anomalous?

CD: It's absolutely real time.  Once this information--I call it "user context"-- is in the system, all of it can be referenced in real time.

It's more than just being able to say these four different usernames are really the same person. You can go beyond that to say these four different usernames are that person and this person is a database administrator and they work in this department and here is their manager and when you see them try to access the data center, is that a segregation of duties issue? Should this database administrator be accessing a data center where critical systems reside?

SJW: So would you refer to that as a roles-based rule?

CD: Yes, I would say that's a roles-based rule or rule violation or segregation of duties issue.

SJW: One of the things that struck me as interesting, as I was reading an ArcSight white paper ["Extracting Value from Enterprise Log Data"], is how complex the SIEM universe is. It talked about how companies may have homegrown systems, that a lot of the applications contribute data in different formats--it's not as easy as I thought it was to pull all of that data together and get a view of your logical security universe. Is that the current state of things, and how might the ArcSight platform insulate security people from some of that complexity?

CD: Just to be fair I haven't read the white paper you've spoken of, but I can address those questions. You do find...systems that customers have built themselves that are doing things like stock trade transactions. You find systems that are very legacy, that don't really produce event logs as we think of event logs. Over the last couple of years, products have really been driven to produce very detailed audit records. With compliance and all the different regulations out there, products have really been pushed in that direction. But if you go back 10 years, you have products that don't do any logging or at a minimum record who logged in.

Page:   1   2  Next  »

Convergence Driven by Information Security

When researching a story about how enterprises can achieve a comprehensive, correlated view of their physical and logical security, Security Squared went to a person who wrote the book on the subject. That's Colby DeRodeff, Thumbnail image for ColbyDerodeff.jpga co-author of Physical and Logical Security Convergence: Powered by Enterprise Security Management, and enterprise strategist for ArcSight, the leader in security information and event management (SIEM) tools as per the Gartner Group in June 2009.

SIEM solutions are analogous to physical security information management systems (PSIM), correlating data coming from many logical security tools, such as intrusion detection, antivirus scans, firewalls, routers, etc. In this first part of his conversation with Sharon J. Watson, DeRodeff deals with technical issues for converging physical and logical event data.

What follows is an edited transcription of our conversation, edited for clarity. Part Two will post September 1.

*********

Sharon J. Watson: What has to happen to connect and correlate data you get about logical security events and physical events so you can get a really good look at what is an imminent threat or a threat that's unfolding as well as pull trending data so you can anticipate and stop some things?

Colby DeRodeff: One of the biggest challenges that you have in trying to correlate physical security data with logical data is the disparity between how those different systems identify individuals. An example of that: at the very basic convergence level, you're trying to compare logs from a badge reader to logs from a domain controller that is allowing me to authenticate to the network. When I look at the log from a badge reader, that badge reader system usually will identify Colby as a numbered ID, like 123457. The domain controller that's doing the network authentication will identify Colby as my domain logon ID, ColbyDeRodeff or CDeRodeff, or what have you.

When I try to do a systematic comparison of those two values, they don't really match up.

So I wouldn't be able to say this ID equals Colby. One of the first places where SIEM or the ArcSight platform allows you to start doing this comparison is using a technology we call IdentityView and identity correlation. We allow you to map to a common identifier.  

For example, let's say I was collecting phone records and e-mail and physical logs and Windows event logs. All of those different log sources are going to identify me differently. What identity correlation does is tie those four different attributes back to one common identity, so I would basically be tying all of those back to Colby DeRodeff.

SJW: The one identity that it ties them back to--who defines it, where does it reside? Is that in the identity management system or Active Directory or an LDAP?

CD: Typically you're going to find that in either an identity management solution or in Active Directory. Active Directory really is an identity management solution in all senses. Organizations sometimes use other products for provisioning. Where you decide that unique ID is doesn't really matter as long as you have one source telling me this is the unique ID that you're going to use for each user.

SJW: Your platform would also tie in data from a physical system, or is it purely in the logical space?

CD: No, our product correlates pretty much anything that you want. I've worked with customers to bring in logs from video analytics systems, logs from HVAC systems, alarms from glass breaking sensors, records about who's coming in through a door or turnstile. The system doesn't really care what type of data it's correlating. Like I said, the biggest challenge is that you need to be able to tie these back to one individual. That's what we allow you to do.

There are a lot of other challenges related to convergence that are not so much technology challenges. There are also a lot of challenges with first getting people to understand why it's important. It's actually easier for someone to steal a laptop that has customer information on it than it is for someone to write a sophisticated buffer overflow or hacker exploit to get into the database that has that information. That's one example.

Another challenge is that these organizations are historically disparate: you have a physical security team and then you have a logical or network security team. A lot of times you'll find these people don't even know who the other team is or where it is in the organization. So there is very poor communication.

One thing I've also found to be a challenge is if organizations are renting or leasing space...the building security is not actually part of the company. Let's say I have floors 10 through 20. There are a lot of other companies in the building as well, the badges are issued by the building, not necessarily the company, so sometimes getting access to that data can be a challenge.

SJW: I want to take you back to the solution you outlined for me using the ArcSight platform and tying those identities together.  Is that purely forensic or does that become real time so it can contribute to monitoring events across all those systems and identify when a particular identity is doing something that is anomalous?

CD: It's absolutely real time.  Once this information--I call it "user context"-- is in the system, all of it can be referenced in real time.

It's more than just being able to say these four different usernames are really the same person. You can go beyond that to say these four different usernames are that person and this person is a database administrator and they work in this department and here is their manager and when you see them try to access the data center, is that a segregation of duties issue? Should this database administrator be accessing a data center where critical systems reside?

SJW: So would you refer to that as a roles-based rule?

CD: Yes, I would say that's a roles-based rule or rule violation or segregation of duties issue.

SJW: One of the things that struck me as interesting, as I was reading an ArcSight white paper ["Extracting Value from Enterprise Log Data"], is how complex the SIEM universe is. It talked about how companies may have homegrown systems, that a lot of the applications contribute data in different formats--it's not as easy as I thought it was to pull all of that data together and get a view of your logical security universe. Is that the current state of things, and how might the ArcSight platform insulate security people from some of that complexity?

CD: Just to be fair I haven't read the white paper you've spoken of, but I can address those questions. You do find...systems that customers have built themselves that are doing things like stock trade transactions. You find systems that are very legacy, that don't really produce event logs as we think of event logs. Over the last couple of years, products have really been driven to produce very detailed audit records. With compliance and all the different regulations out there, products have really been pushed in that direction. But if you go back 10 years, you have products that don't do any logging or at a minimum record who logged in.

<!--nextpage-->

It's very easy to make what we call connectors. Connectors are software that reads the login information from these different systems and brings it into the platform for correlation. It's very easy to build these connectors for products that are common off-the-shelf products that are doing some level of logging. The challenge really is these homegrown applications.

We can do a couple different things. We have a technology called a flex connector. A flex connector is basically a toolkit that allows the user, through a graphical interface, to basically take any log file from any system and map it...to normalize it into our view of the world.

So this allows you to basically bring in a log from any application regardless of whether ArcSight has seen it before. I've seen hospitals bring in logs from medical devices. Now as a company, we don't really have access to medical devices per se, but the customer has lots of logs from these devices so they use this flex connector capability to map these into the ArcSight world. That's one way we help.

This is something that's really interesting: as I mentioned, a lot of these legacy applications don't really do logging, so we provide what we call ArcSight's common event format. You can use it like a library to plug into an application to allow it to start logging. Once it logs using this common event format, then the messages that are generated will be automatically parsed and accepted or read in by the ArcSight platform.

[Legacy systems] are a challenge, and those two items essentially allow you to overcome those challenges.

SJW: On the physical system side, where you have all the variety of sensors and video surveillance, video analytics, the door readers and the badging systems and physical access control and building automation and all of that....there are a group of PSIM vendors, physical security information management vendors. They are the ones who have the connectors into all of those physical event sources. I'm wondering, would you prefer to connect to a normalized stream coming from them? I'm trying to get a feel for what the architecture might be.

CD: If a customer has one of these products--Proximex for example, if they have that installed, we'd partner with them. It would be a great advantage for us to connect into this aggregation point rather than go out to all the devices ourselves. Similarly, in the medical device field, there is a product called Fair Warning, which is a partner of ours. We could use our connectors to go out to all these individual products but if there's already an aggregation point where this data is being centralized, then we would certainly connect with those products and pull that into ArcSight. It's really more how the customer wants to go about it. It's not a requirement but it is certainly a benefit.

SJW: Would how the customer wants it done depends on whether IT or physical security is driving the convergence? I'm trying to get a feel for how the politics affect the solutions.

CD: My experience has mostly been with the logical security team mandating that they will be collecting the physical security logs. This usually comes down from the CSO or the C-Level. It's been a mandate. The physical security team just falls in line. I have never been involved in direct engagement with the physical security team first and then had them asking for the logical security data. I haven't seen it work that way. It could happen like that. I just haven't seen it.

SJW: It's a point of interest for me: I understand the reasons why the physical and logical security teams tend to be separate but it seems like there is so much value for the two of them to be working together more closely that I am flummoxed it doesn't seem to happen more often.

CD: I absolutely agree with you. We've been talking about it for two or three years now but I think it's something that's still in its infancy. I've met some extremely forward- thinking organizations, and these are the ones that are converged. I met with an online brokerage house where all security, whether physical or logical, falls under the chief security officer and he basically controls all the different teams underneath him. But they're a very forward-thinking organization

Also in a lot of military instances, you'll see that the physical security is controlled underneath the logical security as well. That's where I've seen the most focus on physical security or the convergence of the two.

I'm a huge advocate for it. I think people should be doing more. At the end of the day, security is security. If they come over a fence or through the network, they're still causing trouble to the organization.  Even things like looking at air-conditioners going down: the air-conditioners go down and nobody knows about it because nobody's monitoring the AC system and the data center overheats and all the systems are fried, well, you're not doing business. At the end of the day it's all security.

 # # #

Watch for the second half of our exclusive conversation with Colby DeRodeff tomorrow, when he discusses convergence use cases.

More of these can be found in his book Physical and Logical Security Convergence. His co-authors are: Brian T. Contos; William P. Crowell; Dan Dunkel; and Dr. Eric Cole, available at Amazon.com.

Related conversations in this series:

CA Security Management GM Dave Hansen on convergence use cases
Alert Enterprise CEO Jasvir Gill on literally picturing risk for business users
Quantum Secure CTO Vik Ghai on gathering business intelligence from security data
Vidsys--The PSIM Perspective
Proximex--The SIEM-PSIM Connection

No TrackBacks

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

Leave a comment