Part 2: Convergence, driven by SIEM and Information Security

Colby DeRodeff and ArcSight on Convergence in Action

In the first part of our conversation with Colby DeRodeff, enterprise strategist for ArcSight and co-author of the book Physical and Logical Security Convergence, we talked about addressing the technical issues of converging logical and physical event data generated from different sources. In the final portion of our discussion, DeRodeff (pictured)
discusses the need for engaging business users in security discussions, speaking risk language executives can grasp and outlines compelling use cases for convergence.

What follows is an abridged transcript of our conversation, edited for length and clarity.

********************
 
Sharon J. Watson: What need do you see for intelligible data coming out of security systems that business people can understand and use?

Colby DeRodeff: People are experts in different things. Someone who is a financial analyst may be an absolute expert in understanding how a company is going to perform on the NASDAQ but if you show them the security log, they're going to say 'what is this?!' Just like the inverse: if you show a security expert information about some company, they're not going to know whether it's going to be a good financial performer.

There is definitely this translation layer....What you have to do is abstract it and give it to different parts of the organization as reports and dashboard-type views that are divided by the areas of the business that are being affected. When I report to management, I don't want to say, 'Well, I saw these 10 different security breaches,' because upper management is not going to know how that translates to business risk. What I want to do is provide them a view that says 'here are your six different lines of business, here are the ones experiencing problems.'

From there they can make a decision. They don't want to spend a lot of time wondering. They want a quick report they get in the morning, see it's all green, and not worry about it anymore because they have a lot of other stuff going on. Bringing it to a business level [makes] that whole translation layer extremely important.

SJW: What about the middle layer of people that might be able to identify more of the risks, who know the business processes, who might be able to bring their expertise? Like a finance person who can see the data movements and say it's kind of odd that those transactions are happening the way they're happening, could we look at what's happening in the security logs?

CD: Looking at trends and analysis, statistical deviations? I think this is where we really get beyond this convergence concept. There is a whole other area where we play which is the fraud space. When you're dealing with fraud, it's very much that you're dealing with lines of business, and business users don't know a security log from a Windows system log, right? But you show them trends: this stock trader has been trading in these four different securities for this long and now all of a sudden he's doing a lot of trading in this other one. Is that something suspicious?

A financial analyst could much better answer that question. Same thing with insurance fraud. An insurance fraud investigator is far less concerned with a Windows laptop login or somebody kicking in the back door of the building then they are with whether this life insurance customer made an address change right before they made some major change in their account. When you start getting into these business cases, you're almost moving away from standard security logs into these applications.

SJW: What are some other issues I should be addressing when it comes to correlating  physical and logical event data?

CD: A lot of physical security systems are very legacy. Now there is this whole breed of newer ones that are IP-based and act in real time. But the products deployed currently at a lot of companies are very legacy. They're using legacy protocols, a lot of serial connections.

Some of the door readers--I'm not saying the real time and IP-based ones--but some of the older ones actually store the records of who came in the door at the door. So 50 people come through, and then they'll dump that information to a central server. If I want to look for things as they happen, that puts a big dent in my goal there. There's nothing really you can do about that except be able to correlate things from the past with the present. Which ArcSight can do; it's just not the preferred method.

The other thing with physical security comes when you're looking at cameras. The camera doesn't give you a user name. If I take a picture of something, it's just saying here's a picture of somebody who came through the door but it's not going to say 'this is the user.' There is no identification of that person. So then you really need to be able to do this correlation of badge reader logs to camera snapshot to a login to a server in the data center. It really takes all three pieces tied together to figure out who is this person [pictured while] violating some policy.

SJW: Anything else I should be asking?

CD: When I talk about this subject, I start with the background: why should you even be doing [convergence]....I like to give some examples of why this is important. Then I like to get into the detailed use cases, which is where you really see convergence in action. It takes it beyond just the theoretical to the meat and potatoes.

I call "use cases" specific problems that you're trying to solve. One of the most interesting use cases is around the physical logs from the door readers [and] looking for cloned badges....Think about the [security] key fobs so many people carry. They contain an identifier, which is like this numeric ID. If you place an RFID reader near the fob, it powers up the transponder in the fob and then it transmits the ID. So you build a little RFID reader.

<!--nextpage-->

If you can read the ID, you can collect it, which means you can write it to a blank key fob. It's all very easy to do. Just think if you're on a subway train in Manhattan how many people are wearing their little key fobs hanging on their belts. It would probably work right through their pocket unless they have the thing wrapped in aluminum foil. You theoretically have the little RFID reader in the sleeve of your jacket and go by and scan people, collect a whole bunch of IDs, follow a couple so you know where they work, and then you can use that to get into the building.

So if you're looking at badge reader logs, and you have a user who has done things like badge in but never badge out or it's after five o'clock, I've badged out and all of a sudden I'm badged right back in, or a badge in a couple hours later, that's kind of suspicious.

It's also things like looking at activity on the network after I've badged out of the building. Let's say I left for the day but there still activity occurring with my user account on the network. That means either somebody else is using my account or my account has been compromised. Then there's the classic example of physical and VPN access. Basically I am in the building and someone comes in through the VPN and is using my account.

Then there's piggybacking. That's a hard thing to chase down but you're really not supposed to hold the door for the other 15 people coming back from lunch. I was at a very large bank, talking to them about this. They said, 'it's a policy violation and we need to talk to users about this as part of our awareness training.' [Their thinking was] if you had never badged into the building, there should be no log-ins to your workstation.

If that happened, they would send an automated message to the user account that had logged in, saying 'look, you are in violation of the security policy.' They would reference the policy because everybody has to sign that when they come onboard. They would reference that and say you're supposed to do this. You just route an e-mail directly to that person, and if they don't reply within a certain amount of time, the e-mail then escalates to that person's manager.

That was an interesting example of how you can use automation rather than talking to everyone.

The other areas where I've seen some really cool stuff is around SCADA and critical infrastructure. SCADA systems are basically used to monitor and control electric lines, oil and gas pipelines, processing equipment, measure flows, temperatures, things like that. The problem with SCADA systems is that they are often in very secluded areas. Think of a pipeline that goes all the way across Alaska. You have these little access points. You'll be lucky if they are behind a Master lock and key. Most of the time they're just sitting out there.

The interesting thing is a lot of these little systems have a network port attached to them and a satellite uplink. If you can access one of these out in the middle of nowhere, you can basically have access into the SCADA environment. I've worked with a lot of large oil and gas and energy delivery companies on use cases here.

It's a little bit scary but it's good to know they're thinking about these things. That comes with the times.