RSA on Managing Converged Security Event Data with SIEM tools

| 0 Comments | 0 TrackBacks

Page:   1   2   3  Next  »

SIEM Evangelist Paul Stamp talks about SIEM in a converged world

Gaining a comprehensive view of security requires overcoming physical and logical event boundaries and correlating event data for threat detection regardless of its origin. Security Information and Event Management (SIEM) systems and Physical Security Information (PSIM) systems seem poised to achieve that goal.  The question Security Squared is exploring now is whether they'll do so as partners or separately.

That's one of the questions we brought to Paul Stamp (pictured),
Paul_Stamp.jpg senior product marketing manager with RSA for its enVision SIEM platform. He discussed SIEM capabilities, the potential reach of SIEM platforms into physical event data and what factors will drive business users to demand more convergence of physical and logical event data.

The following is an abridged transcription of our conversation, edited for clarity.

***********
Sharon J. Watson: My understand of security information and event management tools is that they gather log and event data from network hardware elements, software applications and databases, security tools like intrusion prevention and detection, anti-virus programs and so on, and then help you determine whether you've got a problem.

Paul Stamp: That's a pretty good analysis. Think about the three things that they do. First of all, they collect data from all of these various sources that you mentioned. Second of all, they manage that data,  whether it's making sure it's being analyzed in real time, making sure that it's being archived in the right place, making sure that is being protected after you've collected it. There is valuable information in there that might need to be presented in a court of law or might need to be included in a compliance report.

Thirdly they are able to do intelligent analysis on that data, looking for things that might imply that there's something going wrong, whether it's based on events from one source or correlating across multiple sources. We're even correlating with things that aren't necessarily to do with the event stream itself.
For example, there are things we know about the person, things we know about the location or things that we know about the machines that are involved. That's on a real-time basis but also on a historical basis. Let's be honest: the telephone is the best troubleshooting alerting technique. So when the telephone does ring, [you need to] be able to go back and find out what happened leading up to the event, during the event and after the event so you can get a good idea of what really went down and how you can deal with it.

SJW: When it comes to intelligent analysis, Paul, are those rules built into the SIEM system or is it something that customers have to customize and fill in based upon their particular business?

PS: A good amount of this has to be built in. There has to be intelligence built into the tool which is based upon real empirical knowledge of how threats occur at a macro level. There are certain things you need to look for that are indicative of a problem wherever you are. So we believe there should be a comprehensive set of rules, a comprehensive set of reports that will look for those types of patterns.

For example, you look for failures at a firewall followed by a success. That's a good example. Lots of failures at a firewall followed by a success from the same IP address--that implies someone is rattling the cage and eventually managing to open the door.

But at the same time, there needs to be the capability for people to extend and modify those rules to make them work in their own environment. What we try to do is give people enough [function] out-of-the-box to say, 'these are the things that happen across the board,' and then documentation to allow people to modify or extend things so they can apply them to their own business situation. No two environments are the same at the end of the day.

SJW:
I was looking at your website and the list of things enVision can connect to. There's a phrase that says it can connect with essentially any IP-based device. I wondered how much these days those devices include physical event devices--badge readers, physical access control systems, video surveillance systems, visitor management systems, building automation systems--that are more IP-based.

PS: I have a particular example of that. We have one customer who has attached enVision to the temperature controls in their environments. Whenever the temperature at the data center went above a certain level, that would fire off an alarm in enVision. That's just an example.

From a technical perspective, if it's IP-based, if it creates an alarm, there are a number of ways you can get hold of that log, and we can certainly pull it into the system. Then we try to understand each of the log events and what they mean. That's where sometimes we require a little bit of help from the customer because quite often they are custom systems, legacy systems. [We need] to be able to say this [event] is a temperature change, or this is somebody walking in the door, or this is something moving in the video surveillance system.

We're collecting the data, we're understanding it, and then turning that into something...that's useful for the customers to build on. What does that mean from the business perspective? What are the things we really need to look at in our environment that would imply that something is going wrong?

For example, temperatures going above 70F in a normal room might not be a bad thing. But in a freezer? That's where the actual environment specific data comes into it. That is where the real business input is needed.

SJW: Paul, how familiar are you with physical security information management (PSIM) systems that come from vendors like Proximex, VidSys and Orsus?

PS: I am not awfully familiar with them.

SJW: Some of the people creating those systems have come from the IT side of the world and they are envisioning their solutions as SIEM for all the physical event data systems, collecting the data and making it intelligible.  I was curious if you'd had many customers looking at those and whether you could talk about any natural connection points between SIEM and PSIM platforms.

PS: I have not heard of anybody integrating with those particular systems....
We have had people who have taken the capabilities of our system and used their own knowledge to be able to build in their own rules and reports and knowledge to create a more comprehensive solution that looks at both physical and logical environments together. The reason why I think these other [PSIM platforms] have come out is around the knowledge the physical security people like to have built into his or her products when they go out and buy them.

Page:   1   2   3  Next  »

SIEM Evangelist Paul Stamp talks about SIEM in a converged world

Gaining a comprehensive view of security requires overcoming physical and logical event boundaries and correlating event data for threat detection regardless of its origin. Security Information and Event Management (SIEM) systems and Physical Security Information (PSIM) systems seem poised to achieve that goal.  The question Security Squared is exploring now is whether they'll do so as partners or separately.

That's one of the questions we brought to Paul Stamp (pictured),
Paul_Stamp.jpg senior product marketing manager with RSA for its enVision SIEM platform. He discussed SIEM capabilities, the potential reach of SIEM platforms into physical event data and what factors will drive business users to demand more convergence of physical and logical event data.

The following is an abridged transcription of our conversation, edited for clarity.

***********
Sharon J. Watson: My understand of security information and event management tools is that they gather log and event data from network hardware elements, software applications and databases, security tools like intrusion prevention and detection, anti-virus programs and so on, and then help you determine whether you've got a problem.

Paul Stamp: That's a pretty good analysis. Think about the three things that they do. First of all, they collect data from all of these various sources that you mentioned. Second of all, they manage that data,  whether it's making sure it's being analyzed in real time, making sure that it's being archived in the right place, making sure that is being protected after you've collected it. There is valuable information in there that might need to be presented in a court of law or might need to be included in a compliance report.

Thirdly they are able to do intelligent analysis on that data, looking for things that might imply that there's something going wrong, whether it's based on events from one source or correlating across multiple sources. We're even correlating with things that aren't necessarily to do with the event stream itself.
For example, there are things we know about the person, things we know about the location or things that we know about the machines that are involved. That's on a real-time basis but also on a historical basis. Let's be honest: the telephone is the best troubleshooting alerting technique. So when the telephone does ring, [you need to] be able to go back and find out what happened leading up to the event, during the event and after the event so you can get a good idea of what really went down and how you can deal with it.

SJW: When it comes to intelligent analysis, Paul, are those rules built into the SIEM system or is it something that customers have to customize and fill in based upon their particular business?

PS: A good amount of this has to be built in. There has to be intelligence built into the tool which is based upon real empirical knowledge of how threats occur at a macro level. There are certain things you need to look for that are indicative of a problem wherever you are. So we believe there should be a comprehensive set of rules, a comprehensive set of reports that will look for those types of patterns.

For example, you look for failures at a firewall followed by a success. That's a good example. Lots of failures at a firewall followed by a success from the same IP address--that implies someone is rattling the cage and eventually managing to open the door.

But at the same time, there needs to be the capability for people to extend and modify those rules to make them work in their own environment. What we try to do is give people enough [function] out-of-the-box to say, 'these are the things that happen across the board,' and then documentation to allow people to modify or extend things so they can apply them to their own business situation. No two environments are the same at the end of the day.

SJW:
I was looking at your website and the list of things enVision can connect to. There's a phrase that says it can connect with essentially any IP-based device. I wondered how much these days those devices include physical event devices--badge readers, physical access control systems, video surveillance systems, visitor management systems, building automation systems--that are more IP-based.

PS: I have a particular example of that. We have one customer who has attached enVision to the temperature controls in their environments. Whenever the temperature at the data center went above a certain level, that would fire off an alarm in enVision. That's just an example.

From a technical perspective, if it's IP-based, if it creates an alarm, there are a number of ways you can get hold of that log, and we can certainly pull it into the system. Then we try to understand each of the log events and what they mean. That's where sometimes we require a little bit of help from the customer because quite often they are custom systems, legacy systems. [We need] to be able to say this [event] is a temperature change, or this is somebody walking in the door, or this is something moving in the video surveillance system.

We're collecting the data, we're understanding it, and then turning that into something...that's useful for the customers to build on. What does that mean from the business perspective? What are the things we really need to look at in our environment that would imply that something is going wrong?

For example, temperatures going above 70F in a normal room might not be a bad thing. But in a freezer? That's where the actual environment specific data comes into it. That is where the real business input is needed.

SJW: Paul, how familiar are you with physical security information management (PSIM) systems that come from vendors like Proximex, VidSys and Orsus?

PS: I am not awfully familiar with them.

SJW: Some of the people creating those systems have come from the IT side of the world and they are envisioning their solutions as SIEM for all the physical event data systems, collecting the data and making it intelligible.  I was curious if you'd had many customers looking at those and whether you could talk about any natural connection points between SIEM and PSIM platforms.

PS: I have not heard of anybody integrating with those particular systems....
We have had people who have taken the capabilities of our system and used their own knowledge to be able to build in their own rules and reports and knowledge to create a more comprehensive solution that looks at both physical and logical environments together. The reason why I think these other [PSIM platforms] have come out is around the knowledge the physical security people like to have built into his or her products when they go out and buy them.

<!--nextpage-->

SJW: Paul, when people want to correlate more of their physical and logical event data, what is the driver?

PS:
The drivers we're seeing now are around the real changes in the way we work. A lot of it is to do with physical mobility. Since we are no longer confined to a particular office or within a geography, that extra physical element becomes important for being able to work out exactly what happened leading up to an incident or during an incident and after an incident occurred, when you're sorting out what needs to be done.

For example, if you have a sensitive HR application, it's fine if somebody is accessing that from their office. It's not fine if they're accessing it from in the cafeteria. Sometimes it isn't is difficult to build those controls into the application so but it's useful to be able to create reports and discourage this type of bad or less than optimal behavior among employees.

That's just an example of where we really see that drive for building physical information into our logical decision-making process.

SJW: Provided that the thing is IP-based and creating some kind of log, it can be brought into a SIEM tool?

PS: That's right.

SJW: As more physical security systems and devices become IP-based, as that segment of the industry gets more open, are you thinking more IT people are going to be wanting more of that data pulled into a SIEM as a good business practice? How do you see that shaking out?

PS: Actually there are two catalysts that are going to make that more of a requirement. The first is the migration of all these physical systems onto an IP network, which makes them susceptible to some of the same security vagaries and similar compliance mandates that an IP-based network is subject to.

The second thing is the organizational convergence, when you have the same people involved in first of all identifying problems in the physical and logical security environment; responding to those incidents and remedying situations; and third of all, demonstrating in one place how the physical and logical security intertwine and how effective the different measures are both on the physical and the logical side, how they are working together to mitigate risks at a high level.  

The technical convergence and the organizational convergence are really going to drive the reasons why people are going to want these things in the same system. I don't think it's necessarily IT folks that are going to want them in the same system. I think it's going to be driven more by the business.

SJW: What kind of data might be able to be pulled from an SIEM platform that could address larger business questions?

PS: Since some of the value that people are getting from this information...is point in time infrastructure operations problems. For example, errors coming from a physical system might imply a door isn't closing properly, for example. That's a fairly operational, down-to-earth purpose.

Because you have all that data, you can start putting it in aggregate form and start to make more meaningful conclusions about utilization, about capacity planning, about where some of your investment resources need to be put in the future.

<!--nextpage-->

SJW: Is that the kind of information people can pull directly out of enVision or is there another analytics or executive management tool needed on top of it?

PS: That's something that could be pulled out of enVision. We can certainly do an analysis on counts of things that are happening, we can certainly do analysis on how things are changing over time. That's something that comes out of the box.

SJW: I have heard that a lot of the data the SIEM systems collect isn't very intelligible to business users.

PS: We take the information as it comes in, and we map it to a taxonomy, to say, for example, this is a logon. Once you take all of those in the aggregate, you can start to display it in forms that are both more appealing to the eye, more appealing to the business user from a visual perspective but that are also describing things that more resemble English and natural language than the actual log format.

SJW: About this topic of really pulling together physical and logical event data: what would you recommend I be thinking about, what should I have asked you that I haven't?

PS: In order for this to work properly, you always have to remember the limitations for this are not usually technical, they are political. The more technical hurdles you can pull out of the way to facilitate that political discussion, the better.  It has to be simple to pull information from these systems, no matter where they are, to be able to create the report, create the alerts, so you can spend your time working at a business level: What are the things you need to be looking at rather than having them messing around with the technology. That's the first part: it has to be simple to use.

The second thing is that we can't be constrained by a specific set of use cases. You've got to be able to pull in that information in the hope you can identify those problems as they occur, or on a historical basis, go back and see if something has happened and then be able to take that empirical data and create rules for the things you want to look at going forward. It has to be flexible enough to support a number of use cases rather than just saying here are the number of bad things we're going to look for and set it off and off it goes. It has to facilitate that discussion around the ongoing use cases.

SJW: In terms of linking events to an identity, how tight is the integration between enVision and a typical identity management provisioning system?

PS: We can certainly tie the information in the log back to the identity of an individual relatively easily. That is something we are being asked for all the time by our customers interested in an IP address or badge number. We are working to make that easier all the time.

SJW: When an alert comes up on an SIEM screen, where is the screen and who is looking at it?

PS: We don't necessarily believe that the screen is the place where most people look at or would like to receive alerts. We think our users prefer eyes on Blackberry rather than eyes on the screen. So we built a lot of our models and we encourage our customers to build their response models around...being alerted with a meaningful information set, and they can go to a web-based console anywhere to get further information about what's going on. That facilitates more flexibility from a process perspective and also organizationally, so you are not constrained by making sure the use cases are being carried out by particular people at particular times.

SJW: Anything you came prepared to talk about that we haven't or something you wanted to emphasize?

PS: We can't divorce the technology from the organization and the process. The technology has to support the way the organization is built and the way it runs. It has to be able to support a fairly simple deployment to start with and also the capability to make that deployment more intelligent and complex as needed as the organization matures in its IT methodologies and ways it wants to deal with these problems.

###

Query: Which system in your enterprise is most likely to be the collecting point for physical and logical event data?

Please be sure to see the list of related entries on this topic.

No TrackBacks

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

Leave a comment