CA's Dave Hansen Discusses Convergence and Identity Management (First of Two Parts)

| 0 Comments | 0 TrackBacks
HansenCAFinal.jpgAs Security Squared dives ever deeper into identity management, exploring physical and logical identity convergence possibilities, we're getting perspectives from some sources who bridge the IT and physical identity worlds. For software giant CA, Dave Hansen (pictured), corporate senior vice president and general manager, CA Security Management, fits that bill.

CA offers an array of logical security products, including Identity Life Cycle Management, a suite of software tools that includes CA Identity Manager and CA Role & Compliance Manager, which Hansen described as a "big analytics engine" designed to correlate user accounts across disparate IT systems to a single identity as well as to suggest and define user roles.

Senior producer Sharon J. Watson talked with Hansen about his perspectives on logical and physical provisioning, whether and how identities can be converged across IT and physical systems, what's the best way to achieve two-factor authentication and more.

The following is the first part of an edited, abridged version of the conversation. The second part will be posted tomorrow.

Dave Hansen: So to step back a little: my background is running IT organizations. I've actually implemented several badge systems from the IT side so I understand the physical side pretty well. Prior to this role, I was CIO of CA too, so now I'm running one of our largest business units. So my perspective is a little different. People finish talking to me and go, Oh, that's a different perspective than other people shared. It tends to be very real world sometimes because I've had to live with some of the pain of these ideas not always having the right use cases.

So if I look at CA Identity Manager as a pure play provisioning application that integrates with HR applications and makes sure we provision the user access into multiple platforms, applications, everything, that's a fairly mature business that people have been involved with for a while. I think what's happening is pressure to make this a lot more simple and a lot smarter and quicker and easier to manage is part. So the role part of [provisioning] is what I think is driving a lot of activity.

The provisioning side is important. The really critical aspect of it, moreso from a compliance point of view, is the de-provisioning side of the house. Making sure within these applications that if someone leaves or they're on sick leave or maternity leave or something like that, their access is taken away effectively, and you're able to prove that. I think that's one of the key things.

Sharon J. Watson: When your schematics show CA Identity Manager connected to card management systems (CMS), what kind of data is coming out of Identity Manager to those systems and what data from the CMS might flow to CA Identity Manager?

DH: The main thing that would come out is new employee starts. Let's go through that process. A new employee starts: Sharon joins CA, HR will put you into SAP. That starts the process. So you're in SAP; CA Identity Manager will pick up the change from SAP, then say, Sharon needs an Active Directory account, email account, might need a mainframe account. Sharon also needs a badge. We're not going to make the badge, but we can send the badge system your name, PMF key, your start date. The badge system can take that and say, I've got a new employee.

That is a key integration point on this journey that people are looking at for convergence. Because the first step is provisioning to that, sending the information over. Right now a lot of people do that. Not everyone does, but people are trying to go down that path.  This challenge comes as well: Sharon leaves CA, we make you inactive in SAP, as soon as that happens, we'd also send the record to badging system to deactivate your badge.

So there are the two touch points coming from identity management. We've been doing a lot of discovery work on this whole topic, we're trying to see what are some of the drivers to come back from the badge system. Today, [it's] not much. The only thing that could happen there is that the badge system would decide to deactivate someone. We'd be very hesitant to then trust that.

If security deactivates someone, it could be for a lot of reasons that we wouldn't necessarily want to propagate back and change. Rarely does the security department deactivate someone because they were terminated. They'd deactivate someone because I was an idiot and forgot to bring my badge in this morning. So they'd issue a new badge and deactivate the old. But I don't really care so much from an HR perspective about that. I could say I'd like to know because I'm going to bill the person for a new badge.

Today, we don't see too many people sending too much back yet from badging sytem.

The other thing to be cognizant of is if an employee leaves and we don't send that to the badge system, somehow integrate that and let [physical system] know, there's an employee running around with a badge who can enter the premise. So the logical system access has been taken away but the physical system access has not. [At CA], we actually run our compliance stuff on the badge system. It's relatively independent, but we bring in the HR record from SAP and compare it to make sure there aren't any possible people who don't have an HR record who have a badge.

SJW: Dave, what you've described sounds like a real clean process that I might expect from a company like CA. How often is [deprovisioning] that clean among your customers and prospects?

DH: I tell a good story. It's not. It's complicated, right? We've had our badging system here for a long time. I've been here seven and a half years, and we've had the badging system a lot longer than that. We've had some of our own technology doing some of this, our own workflows we've managed for a long time. It's a process we've figured out pretty well. I'm pretty proud of how we do this at CA. 

When I talk to other people, it's really, really hard. It's complicated because there are really different systems. One thing we do incredibly well is we have a standardized badge system around the world. My badge works in every CA office in the world. The main exceptions would be the Manhattan office that requires a badge to get access to the building because it's not our building. Then once I get in, I need my CA badge to get into our floor and offices. That badge works in downtown London, it works in our European headquarters out by [London's] Heathrow [Airport], it works in Australia.

One of the biggest issues is that as companies go through mergers and acquisitions, they have offices in different locations, a lot of times they have independent systems within each of those locations. That's probably one of the biggest barriers people have and you wind up having to do a lot of integration work to manage that by location. If we had to write a different utility to provision access to our office in the U.K. vs. the New York office vs. Dallas--that'd be really hard.

Then if you're a traveling employee, you'd have a deck full of badges to get into different offices. I literally travel with two badges, that's all I ever have. One is to open the Manhattan office building, then the CA badge. That's all I travel with. With the exception of the data center, there's not much I can't get into. So I think that [disparity of badge systems] is a big obstacle.

SJW: Does the subject of integrating with other physical security system components ever come up, such as tapping into IP video surveillance cameras or into IP-addressable doors and locks?

DH: Yeah, the doors and lock stuff comes up. The video -the video stuff, I have not run into that too often. What I run into is some very interesting use cases...

The big opportunity with the convergence is really using the badge or physical access system as a multifactor authentication device. That is the big opportunity. The opportunity to integrate the provisioning side and making sure people have badges is half of it--maybe not even half, but definitely a big component of this thing I look at as this convergence.

....What is happening is people want to take that next step, and they feel they need an intelligent physical access device for two-factor authentication. The card is a good solution.

Going back to the lock question, it is intriguing to know where somebody is when they are performing an IT function. This is the ultimate in convergence, right? If you know at CA I'm in my office when I'm authenticating or doing something, that's an interesting piece of information. That would be the default [location]. But then if I'm authenticating in some other place, that's where some bells might go off.

So if I'm physically in the office building, and I'm authenticating in the payroll department, that'd be kind of strange. That would then create some investigation. So the physical piece of that now, going back to the maturity of it, today, I actually have to swipe in to get my car in the parking lot, then I swipe again at the turnstile to get into the building. I have not swiped since, and I'm on the sixth floor of the building.  So nobody knows where I am.

On this floor, there's a swipe station, but it opens up at 8 a.m. So before 8 o'clock, I have to swipe in. I was in the cafeteria at 8 a.m., so I didn't come up until after, so no one knows where I am physically. And that's okay from a physical side, they don't really want that, but if you wanted to have the granular detail....there's a company I know we work with that does the locking mechanisms, and they are remote wireless devices that would verify my access control against my card versus the lock and let me in that door if it was appropriate.

So there's that piece...and the other piece we're working on, we do this today, we partner with a company that does software strong authentication where you don't need a hardware device, where they do a risk assessment based on where you are authenticating from.

If I'm authenticating from the CA network somewhere, that's all they would really care about. If I authenticate from a VPN connection, it might say, oh, we need to challenge this guy a little more because he doesn't normally do that. Or if I authenticate from a different country, and they would know that by the subnets coming in from that part of the world, they might seriously challenge me with a lot more questions to really verify that it's me.

In that use case...the logical guys could tell the physical guys where I was. I don't think people have really thought of it that way. They've always thought the physical guys know. But I think there's a software logical piece, based on IP addresses and routers and where things are coming in from, that you could make a pretty good guess at a high level where somebody is if you needed to let people know.

The physical guys might want to know where their executives are at all times. Now that's kind of big brother-ish, I don't know what the use case is on this, but that type of convergence would provide a different level of information than was ever really thought of being provided before.

Tomorrow: The difference between an IP addresses and a physical location, the integration of physical security into IT access control and the fundamental building block in converged identity and access management.
HansenCAFinal.jpgAs Security Squared dives ever deeper into identity management, exploring physical and logical identity convergence possibilities, we're getting perspectives from some sources who bridge the IT and physical identity worlds. For software giant CA, Dave Hansen (pictured), corporate senior vice president and general manager, CA Security Management, fits that bill.

CA offers an array of logical security products, including Identity Life Cycle Management, a suite of software tools that includes CA Identity Manager and CA Role & Compliance Manager, which Hansen described as a "big analytics engine" designed to correlate user accounts across disparate IT systems to a single identity as well as to suggest and define user roles.

Senior producer Sharon J. Watson talked with Hansen about his perspectives on logical and physical provisioning, whether and how identities can be converged across IT and physical systems, what's the best way to achieve two-factor authentication and more.

The following is the first part of an edited, abridged version of the conversation. The second part will be posted tomorrow.

Dave Hansen: So to step back a little: my background is running IT organizations. I've actually implemented several badge systems from the IT side so I understand the physical side pretty well. Prior to this role, I was CIO of CA too, so now I'm running one of our largest business units. So my perspective is a little different. People finish talking to me and go, Oh, that's a different perspective than other people shared. It tends to be very real world sometimes because I've had to live with some of the pain of these ideas not always having the right use cases.

So if I look at CA Identity Manager as a pure play provisioning application that integrates with HR applications and makes sure we provision the user access into multiple platforms, applications, everything, that's a fairly mature business that people have been involved with for a while. I think what's happening is pressure to make this a lot more simple and a lot smarter and quicker and easier to manage is part. So the role part of [provisioning] is what I think is driving a lot of activity.

The provisioning side is important. The really critical aspect of it, moreso from a compliance point of view, is the de-provisioning side of the house. Making sure within these applications that if someone leaves or they're on sick leave or maternity leave or something like that, their access is taken away effectively, and you're able to prove that. I think that's one of the key things.

Sharon J. Watson: When your schematics show CA Identity Manager connected to card management systems (CMS), what kind of data is coming out of Identity Manager to those systems and what data from the CMS might flow to CA Identity Manager?

DH: The main thing that would come out is new employee starts. Let's go through that process. A new employee starts: Sharon joins CA, HR will put you into SAP. That starts the process. So you're in SAP; CA Identity Manager will pick up the change from SAP, then say, Sharon needs an Active Directory account, email account, might need a mainframe account. Sharon also needs a badge. We're not going to make the badge, but we can send the badge system your name, PMF key, your start date. The badge system can take that and say, I've got a new employee.

That is a key integration point on this journey that people are looking at for convergence. Because the first step is provisioning to that, sending the information over. Right now a lot of people do that. Not everyone does, but people are trying to go down that path.  This challenge comes as well: Sharon leaves CA, we make you inactive in SAP, as soon as that happens, we'd also send the record to badging system to deactivate your badge.

So there are the two touch points coming from identity management. We've been doing a lot of discovery work on this whole topic, we're trying to see what are some of the drivers to come back from the badge system. Today, [it's] not much. The only thing that could happen there is that the badge system would decide to deactivate someone. We'd be very hesitant to then trust that.

If security deactivates someone, it could be for a lot of reasons that we wouldn't necessarily want to propagate back and change. Rarely does the security department deactivate someone because they were terminated. They'd deactivate someone because I was an idiot and forgot to bring my badge in this morning. So they'd issue a new badge and deactivate the old. But I don't really care so much from an HR perspective about that. I could say I'd like to know because I'm going to bill the person for a new badge.

Today, we don't see too many people sending too much back yet from badging sytem.

The other thing to be cognizant of is if an employee leaves and we don't send that to the badge system, somehow integrate that and let [physical system] know, there's an employee running around with a badge who can enter the premise. So the logical system access has been taken away but the physical system access has not. [At CA], we actually run our compliance stuff on the badge system. It's relatively independent, but we bring in the HR record from SAP and compare it to make sure there aren't any possible people who don't have an HR record who have a badge.

SJW: Dave, what you've described sounds like a real clean process that I might expect from a company like CA. How often is [deprovisioning] that clean among your customers and prospects?

DH: I tell a good story. It's not. It's complicated, right? We've had our badging system here for a long time. I've been here seven and a half years, and we've had the badging system a lot longer than that. We've had some of our own technology doing some of this, our own workflows we've managed for a long time. It's a process we've figured out pretty well. I'm pretty proud of how we do this at CA. 

When I talk to other people, it's really, really hard. It's complicated because there are really different systems. One thing we do incredibly well is we have a standardized badge system around the world. My badge works in every CA office in the world. The main exceptions would be the Manhattan office that requires a badge to get access to the building because it's not our building. Then once I get in, I need my CA badge to get into our floor and offices. That badge works in downtown London, it works in our European headquarters out by [London's] Heathrow [Airport], it works in Australia.

One of the biggest issues is that as companies go through mergers and acquisitions, they have offices in different locations, a lot of times they have independent systems within each of those locations. That's probably one of the biggest barriers people have and you wind up having to do a lot of integration work to manage that by location. If we had to write a different utility to provision access to our office in the U.K. vs. the New York office vs. Dallas--that'd be really hard.

Then if you're a traveling employee, you'd have a deck full of badges to get into different offices. I literally travel with two badges, that's all I ever have. One is to open the Manhattan office building, then the CA badge. That's all I travel with. With the exception of the data center, there's not much I can't get into. So I think that [disparity of badge systems] is a big obstacle.

SJW: Does the subject of integrating with other physical security system components ever come up, such as tapping into IP video surveillance cameras or into IP-addressable doors and locks?

DH: Yeah, the doors and lock stuff comes up. The video -the video stuff, I have not run into that too often. What I run into is some very interesting use cases...

The big opportunity with the convergence is really using the badge or physical access system as a multifactor authentication device. That is the big opportunity. The opportunity to integrate the provisioning side and making sure people have badges is half of it--maybe not even half, but definitely a big component of this thing I look at as this convergence.

....What is happening is people want to take that next step, and they feel they need an intelligent physical access device for two-factor authentication. The card is a good solution.

Going back to the lock question, it is intriguing to know where somebody is when they are performing an IT function. This is the ultimate in convergence, right? If you know at CA I'm in my office when I'm authenticating or doing something, that's an interesting piece of information. That would be the default [location]. But then if I'm authenticating in some other place, that's where some bells might go off.

So if I'm physically in the office building, and I'm authenticating in the payroll department, that'd be kind of strange. That would then create some investigation. So the physical piece of that now, going back to the maturity of it, today, I actually have to swipe in to get my car in the parking lot, then I swipe again at the turnstile to get into the building. I have not swiped since, and I'm on the sixth floor of the building.  So nobody knows where I am.

On this floor, there's a swipe station, but it opens up at 8 a.m. So before 8 o'clock, I have to swipe in. I was in the cafeteria at 8 a.m., so I didn't come up until after, so no one knows where I am physically. And that's okay from a physical side, they don't really want that, but if you wanted to have the granular detail....there's a company I know we work with that does the locking mechanisms, and they are remote wireless devices that would verify my access control against my card versus the lock and let me in that door if it was appropriate.

So there's that piece...and the other piece we're working on, we do this today, we partner with a company that does software strong authentication where you don't need a hardware device, where they do a risk assessment based on where you are authenticating from.

If I'm authenticating from the CA network somewhere, that's all they would really care about. If I authenticate from a VPN connection, it might say, oh, we need to challenge this guy a little more because he doesn't normally do that. Or if I authenticate from a different country, and they would know that by the subnets coming in from that part of the world, they might seriously challenge me with a lot more questions to really verify that it's me.

In that use case...the logical guys could tell the physical guys where I was. I don't think people have really thought of it that way. They've always thought the physical guys know. But I think there's a software logical piece, based on IP addresses and routers and where things are coming in from, that you could make a pretty good guess at a high level where somebody is if you needed to let people know.

The physical guys might want to know where their executives are at all times. Now that's kind of big brother-ish, I don't know what the use case is on this, but that type of convergence would provide a different level of information than was ever really thought of being provided before.

Tomorrow: The difference between an IP addresses and a physical location, the integration of physical security into IT access control and the fundamental building block in converged identity and access management.

No TrackBacks

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

Leave a comment