Sun on Physical/Logical Convergence of Identity and Access Management

| 0 Comments | 0 TrackBacks
Security Squared continues to explore identity and access management (IAM) from IT and physical security perspectives. For more on the IT view of IAM and its potential intersection points with physical identity, Sharon J. Watson spoke with Daniel Raskin, chief identity strategist at Sun Microsystems, on May 13.

Raskin, DanielRaskin.jpgpictured, works with Sun product teams to define product road maps, requirements, and directions. He also works to ensure products align with the company's broad identity strategy, which he is responsible for defining.

Raskin explained Sun's commitment to offering a simplified, practical identity management architecture; what's driving adoption of various components of identity and access management; and whether there's a use case for converged physical and logical identity management.

What follows is an edited and abridged transcript of our conversation.

On what enterprises are trying to solve with identity management tools:

People come in wanting to do basic things to lower operational costs...like password resets or provisioning users or doing compliance and attestation and want to meet rules like Sarbanes-Oxley or J-SOX [the new Japanese audit standards similar to SOX] or some other standard or set of regulations like Basel II. They want to solve [those] problems by coming up with a centralized infrastructure to do all that.

The other side of it is more of the run-time activities, the access controls. So when we talk about identity and people still struggling every day with basic problems--those problems are pretty big problems to solve within your data center and it takes a lot of work.

Oftentimes you'll talk to vendors and they're talking about risk-based authentication or virtual directories or SIEM [Security Information and Event Management] or IT-GRC [IT governance, risk and compliance], whatever the next big thing is that everyone's talking about. The reality is...when customers come into Sun to talk about the problems they need to solve, they're still sitting there saying how do I get my provisioning infrastructure set up, how do I just start to do roles. Most organizations haven't completed single sign-on (SSO) and are just starting federation, let alone getting into these more complex things.

So vendors are much farther ahead than organizations are in implementing their identity infrastructure.

On the components of identity management that are growing:

This is a generalization, it totally differs in terms of the maturity curve of where different organizations are, but for the most part, in terms of web access management, they'll have started to solve SSO within their organization. Moving a web access management solution to the extranet to scale to millions on millions of users is something more greenfield...secure web services is more green-field.

Over the last six months to a year, federation seems to be picking up. We've noticed a lot more people focusing on implementing that but it's still early stages for federation.

Provision is the hottest thing right now in terms of implementations just because of the compliance issues that are going on and needing to meet regulatory pressures. That's one of the biggest drivers and what that means is when it comes to provisioning, organizations almost always have a compliance line item in their budget that they use to pay for those types of initiatives.

On role-based provisioning and compliance:

The biggest driver for roles [is] this whole process of writing entitlements, policies of what people access and who has access to what. [Sun Role Manager] is basically a data warehouse for going through and doing the compliance management for that.

So you could have a manager confirm that a role is correct [and] go through the process of compliance and attestation, ensuring employees are associated to the right roles and going through the whole process of allowing your organization to check that all your roles and assignments are correct. So the role piece allows you to simplify that process.

On the benefits of role-based provisioning:

We're seeing a big uptake in roles over the last year or so but it's still early stages yet. The big thing about that is people are building that off their provisioning implementation. They want to move from just user provisioning to role-based provisioning and compliance.

It goes back to simplifying that process. Rather than having to create a user, associate lots of resources to that user and push them into all the application, you're now creating a more streamlined process by doing a couple of things. [Sun Role Manager] looks through all the identity repositories to identify the different types of users to construct roles, so [you have] automated role mining.

Once those roles are created, you can push those roles into your provisioning solution so that rather than having to define a user and individually go through and associate specific resources to that user, all you have to do is assign a role to [the user] and that automatically attaches all the different resources they have access to. It simplifies that process.

On associating access to physical locations and assets, such as handheld devices, with identity roles:

It's newer in terms of where we're seeing people ask for that. It's not something that's in the past been a key requirement for most organizations to implement. But essentially that question does come up and literally, we just treat it like an attribute. Different attributes are required to access a resource, and one of those attributes could be location, it could be IP address, it could be a whole bunch of things that allow someone to have access to different resources depending on where they are. So I wouldn't say it's a common requirement across the board but we do get questions about it.

I know a lot of vendors are marketing it, particularly enterprise SSO vendors seem to be pushing that really heavily....it's not mature in its adoption but rather something people are starting to ask more about.

On granular enforcement of entitlements:

It's where you get into the whole piece of when I create a policy, what are the attributes that are required to either give me a "yes, I can access this resource" or "no, I can't." That can be a whole slew of things. And with entitlement enforcement, what we're doing now is not just about access to the resource, but it's much more fine-grained than that. It could be access to a specific page within a web site or a specific field within a web site or an image.

For example, we have a scenario we've played out with banks in terms of fine-grained authorization. This is slightly different from physical-logical but you can easily tie to it. We do multifactor authentication or two-factor authentication with cell phones through our access management solution. Rather than just requiring someone to use that second factor of authentication when they log in, what we do is when they get to certain parts of an application--for example, paying a bill or transferring money--we require them to have a second factor of authentication to access that [function].

In this case, it'd be pressing a button, the system sends a one-time password to your cell phone, you see that one-time password, you enter it in, then you can access that part of the site to transfer money or to pay a bill.

What you can do with physical and logical that gets interesting: if I'm at a certain IP address or I'm within a certain location, I can make it where I don't need that second factor of authentication because I'm in the building. But if I'm external, I'm at a Starbucks or somewhere else, you can very easily provide that second factor of control to choose that.

On risk-based algorithms for authentication:

But what'd I say is probably more common...is a lot of questions and more technologies popping up around risk-based authentication and authorization that is focused more on using different types of algorithms to check keystrokes and analyze whether there's risk associated with someone logging into an application based on all kinds of things - location, keystroke types, all kinds of things that it's looking at.

The interesting thing about that is there's no change to the user experience. In other words, if I'm Verizon, and I want to implement a second factor of authentication to access a specific page on a site, that requires training people on how to actually do that second factor of authentication--how do I actually send something to my cell phone, how do I actually get this unique ID and submit it--whereas with risk-based authentication, it's all behind the scenes.

On adding physical location to authentication and "identity sprawl:"

Today, I think the problem of identity sprawl still exists for most solutions. If you were doing a web access management solution and you wanted to do a second factor of authentication based on physical/logical location, [most solutions] would require deploying a second product, an ActivIdentity or PassLogix or SafeWord solution. So I think as there's more consolidation of multifactor authentication technology into access management solutions, you'll see more adoption and implementation of those things. So that's a key part of our strategy.

For example, as of June, we actually have multifactor authentication built into Enterprise OpenSSO so when someone's constructing a policy [and mixes it] with entitlement enforcement, they can say, based on the attribute of the location, [users] need to do a second factor of authentication if they want to access the ability to transfer funds in a banking portal. Or if they're within their home or some registered IP address that's known, they have access without that second factor.

On building use cases for converged physical/logical access management:

This is probably one of the most common things we come across in identity: we go first to the technology, and then we look for the use cases and the value of where it's going to have the biggest impact, how it's going to lower operational expenses, how it's going to tie back to compliance and those kinds of things to help an organization solve a problem.

The reality is I'd look at those pieces first, then map the right technology onto them. You can see this with things like OpenID, InfoCards and CardSpace, where we as vendors in the industry [have] put together all these technologies that have cool ways of providing access to applications in a simplified way -- but it seems like we chase the use cases afterward in terms of how to apply it or who's going to adopt it, do service providers want this type of stuff.

So with physical/logical [access management], is it just about the run-time access or is it there a whole compliance and auditing side to it as well? It's finding that sweet spot of where it fits and if it fits. To be honest, when it comes to physical/logical, I don't know what that is yet.
Security Squared continues to explore identity and access management (IAM) from IT and physical security perspectives. For more on the IT view of IAM and its potential intersection points with physical identity, Sharon J. Watson spoke with Daniel Raskin, chief identity strategist at Sun Microsystems, on May 13.

Raskin, DanielRaskin.jpgpictured, works with Sun product teams to define product road maps, requirements, and directions. He also works to ensure products align with the company's broad identity strategy, which he is responsible for defining.

Raskin explained Sun's commitment to offering a simplified, practical identity management architecture; what's driving adoption of various components of identity and access management; and whether there's a use case for converged physical and logical identity management.

What follows is an edited and abridged transcript of our conversation.

On what enterprises are trying to solve with identity management tools:

People come in wanting to do basic things to lower operational costs...like password resets or provisioning users or doing compliance and attestation and want to meet rules like Sarbanes-Oxley or J-SOX [the new Japanese audit standards similar to SOX] or some other standard or set of regulations like Basel II. They want to solve [those] problems by coming up with a centralized infrastructure to do all that.

The other side of it is more of the run-time activities, the access controls. So when we talk about identity and people still struggling every day with basic problems--those problems are pretty big problems to solve within your data center and it takes a lot of work.

Oftentimes you'll talk to vendors and they're talking about risk-based authentication or virtual directories or SIEM [Security Information and Event Management] or IT-GRC [IT governance, risk and compliance], whatever the next big thing is that everyone's talking about. The reality is...when customers come into Sun to talk about the problems they need to solve, they're still sitting there saying how do I get my provisioning infrastructure set up, how do I just start to do roles. Most organizations haven't completed single sign-on (SSO) and are just starting federation, let alone getting into these more complex things.

So vendors are much farther ahead than organizations are in implementing their identity infrastructure.

On the components of identity management that are growing:

This is a generalization, it totally differs in terms of the maturity curve of where different organizations are, but for the most part, in terms of web access management, they'll have started to solve SSO within their organization. Moving a web access management solution to the extranet to scale to millions on millions of users is something more greenfield...secure web services is more green-field.

Over the last six months to a year, federation seems to be picking up. We've noticed a lot more people focusing on implementing that but it's still early stages for federation.

Provision is the hottest thing right now in terms of implementations just because of the compliance issues that are going on and needing to meet regulatory pressures. That's one of the biggest drivers and what that means is when it comes to provisioning, organizations almost always have a compliance line item in their budget that they use to pay for those types of initiatives.

On role-based provisioning and compliance:

The biggest driver for roles [is] this whole process of writing entitlements, policies of what people access and who has access to what. [Sun Role Manager] is basically a data warehouse for going through and doing the compliance management for that.

So you could have a manager confirm that a role is correct [and] go through the process of compliance and attestation, ensuring employees are associated to the right roles and going through the whole process of allowing your organization to check that all your roles and assignments are correct. So the role piece allows you to simplify that process.

On the benefits of role-based provisioning:

We're seeing a big uptake in roles over the last year or so but it's still early stages yet. The big thing about that is people are building that off their provisioning implementation. They want to move from just user provisioning to role-based provisioning and compliance.

It goes back to simplifying that process. Rather than having to create a user, associate lots of resources to that user and push them into all the application, you're now creating a more streamlined process by doing a couple of things. [Sun Role Manager] looks through all the identity repositories to identify the different types of users to construct roles, so [you have] automated role mining.

Once those roles are created, you can push those roles into your provisioning solution so that rather than having to define a user and individually go through and associate specific resources to that user, all you have to do is assign a role to [the user] and that automatically attaches all the different resources they have access to. It simplifies that process.

On associating access to physical locations and assets, such as handheld devices, with identity roles:

It's newer in terms of where we're seeing people ask for that. It's not something that's in the past been a key requirement for most organizations to implement. But essentially that question does come up and literally, we just treat it like an attribute. Different attributes are required to access a resource, and one of those attributes could be location, it could be IP address, it could be a whole bunch of things that allow someone to have access to different resources depending on where they are. So I wouldn't say it's a common requirement across the board but we do get questions about it.

I know a lot of vendors are marketing it, particularly enterprise SSO vendors seem to be pushing that really heavily....it's not mature in its adoption but rather something people are starting to ask more about.

On granular enforcement of entitlements:

It's where you get into the whole piece of when I create a policy, what are the attributes that are required to either give me a "yes, I can access this resource" or "no, I can't." That can be a whole slew of things. And with entitlement enforcement, what we're doing now is not just about access to the resource, but it's much more fine-grained than that. It could be access to a specific page within a web site or a specific field within a web site or an image.

For example, we have a scenario we've played out with banks in terms of fine-grained authorization. This is slightly different from physical-logical but you can easily tie to it. We do multifactor authentication or two-factor authentication with cell phones through our access management solution. Rather than just requiring someone to use that second factor of authentication when they log in, what we do is when they get to certain parts of an application--for example, paying a bill or transferring money--we require them to have a second factor of authentication to access that [function].

In this case, it'd be pressing a button, the system sends a one-time password to your cell phone, you see that one-time password, you enter it in, then you can access that part of the site to transfer money or to pay a bill.

What you can do with physical and logical that gets interesting: if I'm at a certain IP address or I'm within a certain location, I can make it where I don't need that second factor of authentication because I'm in the building. But if I'm external, I'm at a Starbucks or somewhere else, you can very easily provide that second factor of control to choose that.

On risk-based algorithms for authentication:

But what'd I say is probably more common...is a lot of questions and more technologies popping up around risk-based authentication and authorization that is focused more on using different types of algorithms to check keystrokes and analyze whether there's risk associated with someone logging into an application based on all kinds of things - location, keystroke types, all kinds of things that it's looking at.

The interesting thing about that is there's no change to the user experience. In other words, if I'm Verizon, and I want to implement a second factor of authentication to access a specific page on a site, that requires training people on how to actually do that second factor of authentication--how do I actually send something to my cell phone, how do I actually get this unique ID and submit it--whereas with risk-based authentication, it's all behind the scenes.

On adding physical location to authentication and "identity sprawl:"

Today, I think the problem of identity sprawl still exists for most solutions. If you were doing a web access management solution and you wanted to do a second factor of authentication based on physical/logical location, [most solutions] would require deploying a second product, an ActivIdentity or PassLogix or SafeWord solution. So I think as there's more consolidation of multifactor authentication technology into access management solutions, you'll see more adoption and implementation of those things. So that's a key part of our strategy.

For example, as of June, we actually have multifactor authentication built into Enterprise OpenSSO so when someone's constructing a policy [and mixes it] with entitlement enforcement, they can say, based on the attribute of the location, [users] need to do a second factor of authentication if they want to access the ability to transfer funds in a banking portal. Or if they're within their home or some registered IP address that's known, they have access without that second factor.

On building use cases for converged physical/logical access management:

This is probably one of the most common things we come across in identity: we go first to the technology, and then we look for the use cases and the value of where it's going to have the biggest impact, how it's going to lower operational expenses, how it's going to tie back to compliance and those kinds of things to help an organization solve a problem.

The reality is I'd look at those pieces first, then map the right technology onto them. You can see this with things like OpenID, InfoCards and CardSpace, where we as vendors in the industry [have] put together all these technologies that have cool ways of providing access to applications in a simplified way -- but it seems like we chase the use cases afterward in terms of how to apply it or who's going to adopt it, do service providers want this type of stuff.

So with physical/logical [access management], is it just about the run-time access or is it there a whole compliance and auditing side to it as well? It's finding that sweet spot of where it fits and if it fits. To be honest, when it comes to physical/logical, I don't know what that is yet.

No TrackBacks

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

Leave a comment