Trusted Computing Group on PAC-NAC Convergence via IF-MAP Standard

| 0 Comments | 0 TrackBacks

Page:   1   2   3  Next  »

Making certain the log-in data coming from a particular PC, laptop or mobile device is actually being entered by the specific human it's assigned to seems like a security no-brainer. Yet as Security Squared has detailed, accomplishing that task is not easy today for most enterprises. Despite its difficulty, the need for physical-logical identity management is growing exponentially with the increasing use of mobile computing and the explosion of cloud computing.

Network infrastructure vendors, including Alcatel-Lucent, Cisco Systems, 3Com (being acquired by HP) and Juniper Networks now talk about identity-aware network gear, though mainly in terms of linking logical identity management to network access control. That's why we were intrigued to see a physical access to network access solution demonstrated at ASIS in September 2009. The demo featured Hirsch Electronics' Velocity security management software sharing information with a Juniper Networks' network access control appliance via a Metadata Access Protocol (MAP) server from Infoblox, a network services platform vendor.
 
All three companies are members of the Trusted Computing Group, a not-for-profit organization creating standards for interoperability in several core computing/networking areas. Other members include Microsoft, IBM, HP, Gemalto, HID Global. (A full member list is here.)  The TCG created the IF-MAP protocol that enables Hirsch software to make physical security data available to a Juniper network access control point--and vice versa.

So as part of our research into what today's network access control capabilities offer for physical-logical identity management, Security Squared's Sharon J. Watson spoke earlier this month with representatives from Hirsch, Infoblox, Juniper and the Trusted Computing Group to better understand the IF-MAP protocol and what it might mean for converged security solutions.

The participants included Bob Beliles, vice president, enterprise business development, Hirsch Electronics; Stuart Bailey, chief technology officer, Infoblox, and chairman of the IF-MAP subgroup with the Trusted Computing Group; Rick Kagan, vice president of marketing, Infoblox; Steve Hanna, distinguished engineer, Juniper Networks and Co-Chair, Trusted Network Connect Work Group, Trusted Computing Group; Moinul Kahn, product line manager for Juniper's Unified Access Control (UAC) product line; Jay Kelley, product marketing manager, UAC, for Juniper.

What follows is a transcript of our conversation, edited for clarity and length. In Part 1, we discuss the IF-MAP protocol basics as well as its potential enterprise security applicability.

********
Sharon J. Watson, Security Squared: One of the things that intrigued me a lot is the PAC-NAC solution as presented in a white paper Bob [Beliles] wrote, which is a combination of Hirsch's Velocity, the Juniper NAC [network access control] equipment and then this metadata [server] from Infoblox, which uses the IF-MAP standard protocol. Can we talk a little bit about that box, and what it accomplishes because it seems very important to being able to link the information coming in from a Hirsch PAC device and the NAC element.

Rick Kagan, Infoblox: I can try that one. It is actually a MAP server. MAP is metadata access point. It's not a policy decision point, it's a database. The way we like to think about it is it's almost like Facebook for things on an IP network. It's a way for different devices to publish information about what's going on about themselves or other devices on the network. Just like you can get a Google alert when something changes out in the world and you get an automatic alert telling you that it happened, various systems can subscribe to the MAP database and look for changes in things of interest.
That could be a user authenticating to the network or that a particular employee has badged into the building.  That information is made available to the MAP database. Any device or system interested in knowing, for example, that somebody badges into the building either previously or at that moment, are able to get that information. So it's a way of facilitating the sharing of information by different kinds of systems: a network access control system, a physical access control system and others very, very easily and in a standards-based way.

But the policy decisions are not made by the MAP database. The policy decisions are made by the physical access control system or the network access control system. They are able to coordinate and still do their own jobs but they do it better because they have more information about what's going on. Now, a network access control decision--do I let this guy on my network?--can be informed by [information about whether] he is physically in the building, for example.

SJW: The MAP server--does that only connect to devices or does it also pull information from any software system?

Rick Kagan, Infoblox
: The server is standards-based, and any system that implements the client side of the MAP protocol can put information into the database if it is authorized to do so and get information from the database. Implementing that client, that way of accessing data from the MAP database,e is technically quite straightforward and simple.

Steve Hanna, Juniper: I just wanted to interject two more things about the standard and protocol. All of these companies--Juniper, Hirsch, Infoblox, a lot of others-- are members of a group called the Trusted Computing Group, which is the standards body that created the standard called I-F MAP. Some people call it IF-MAP. That's the standard protocol that is used to communicate with that MAP server.

In addition to implementing it, each device that wants to store or retrieve data from that MAP server database has to be authorized to do so. You don't want to have just anybody able to get the information. It's pretty confidential or it can be security-related information. So we also require that those devices--software, servers--be authorized to access the database.

Bob Beliles, Hirsch Electronics: It might make sense to go up another level. I think it's important to recognize this group of companies that have come together the Trusted Computing Group is reflective of semi conductor companies, data storage companies, network storage companies, virus protection companies, software companies. All of these IT-oriented companies recognized several years ago the importance of protecting data and protecting the devices on the network that either store the data or transmit the data or end up using or manipulating the data. So that's what really spawned the whole concept of 'we need to take into consideration the behavior of certain devices, of what's going on in the network itself in order to protect the network and the devices attached to it.'
 
That spawned a couple of different initiatives within the Trusted Computing Group and one of those ultimately came out more recently was that this development of this protocol, what I would say is the protocol suite. There are more than 100 trusted computing group members that support these standards today. It's not just Juniper, it's Intel, Hirsch, Infoblox, McAfee, Symantec, Boeing...

Steve Hanna, Juniper: Microsoft...

Bob Beliles, Hirsch: So it's a pretty broad and impressive list of vendor companies. All say, 'Yes this is how we are going to do things.' I think there's some significance your readers would be interested in because of course in the physical security industry, standards or standards discussions are only now just evolving.

SJW: I was just about to ask about that. I didn't hear any physical security vendors in that list of companies. Those [physical security] systems are notorious for being closed and difficult to work with even in an open environment.

Bob Beliles, Hirsch: Right. So to your readers the relevance is, here are more than 100 companies, many of them in the IT industry but Hirsch is there, HID, Gemalto, which does smartcard technology, is there. The point is this is a large cross-section of companies that have basically agreed this is the way we think it ought to be done and this is the way we're going to do it with our particular products. There's a lot of support for these kinds of standards. We're basically not sitting here trying to fight against each other, doing it this way versus that way.
 
So pulling it back toward the IF-MAP protocol...What IF-MAP does is enable any device to communicate its status, what's going on, like Twitter or Facebook such that other devices that are authorized to do so can say, 'Based on that information, is there something else I should be doing?'

To our point of physical access to network access interoperability capabilities using the IF-MAP protocol, Hirsch is publishing access control events, authentication of an individual who is now inside the building, and other devices authorized to do so can then take that information, receive it under effectively a subscription basis from the MAP server, then go apply whatever policy they want.

The nice thing is in terms of delineation--and I know some customers can be concerned about where their information is going or is this the physical security world trying to dictate to the network world what's going on or vice versa--the nice thing is all you're doing is saying 'I have some information to share, I'm going to share it with trusted entities or devices,' then it's up to those devices or those other groups that own those devices to decide whether that information is relevant to them and whether they're going to do anything or not.  

So it's not about one world taking over another world, it's about sharing information between the worlds, establishing what I believe convergence is really all about. It's not just connecting different devices on the network and saying you're done, it's sharing information in a trusted and secure way that's going to make IF-MAP very compelling and very useful in a broad number of applications.

Page:   1   2   3  Next  »

Making certain the log-in data coming from a particular PC, laptop or mobile device is actually being entered by the specific human it's assigned to seems like a security no-brainer. Yet as Security Squared has detailed, accomplishing that task is not easy today for most enterprises. Despite its difficulty, the need for physical-logical identity management is growing exponentially with the increasing use of mobile computing and the explosion of cloud computing.

Network infrastructure vendors, including Alcatel-Lucent, Cisco Systems, 3Com (being acquired by HP) and Juniper Networks now talk about identity-aware network gear, though mainly in terms of linking logical identity management to network access control. That's why we were intrigued to see a physical access to network access solution demonstrated at ASIS in September 2009. The demo featured Hirsch Electronics' Velocity security management software sharing information with a Juniper Networks' network access control appliance via a Metadata Access Protocol (MAP) server from Infoblox, a network services platform vendor.
 
All three companies are members of the Trusted Computing Group, a not-for-profit organization creating standards for interoperability in several core computing/networking areas. Other members include Microsoft, IBM, HP, Gemalto, HID Global. (A full member list is here.)  The TCG created the IF-MAP protocol that enables Hirsch software to make physical security data available to a Juniper network access control point--and vice versa.

So as part of our research into what today's network access control capabilities offer for physical-logical identity management, Security Squared's Sharon J. Watson spoke earlier this month with representatives from Hirsch, Infoblox, Juniper and the Trusted Computing Group to better understand the IF-MAP protocol and what it might mean for converged security solutions.

The participants included Bob Beliles, vice president, enterprise business development, Hirsch Electronics; Stuart Bailey, chief technology officer, Infoblox, and chairman of the IF-MAP subgroup with the Trusted Computing Group; Rick Kagan, vice president of marketing, Infoblox; Steve Hanna, distinguished engineer, Juniper Networks and Co-Chair, Trusted Network Connect Work Group, Trusted Computing Group; Moinul Kahn, product line manager for Juniper's Unified Access Control (UAC) product line; Jay Kelley, product marketing manager, UAC, for Juniper.

What follows is a transcript of our conversation, edited for clarity and length. In Part 1, we discuss the IF-MAP protocol basics as well as its potential enterprise security applicability.

********
Sharon J. Watson, Security Squared: One of the things that intrigued me a lot is the PAC-NAC solution as presented in a white paper Bob [Beliles] wrote, which is a combination of Hirsch's Velocity, the Juniper NAC [network access control] equipment and then this metadata [server] from Infoblox, which uses the IF-MAP standard protocol. Can we talk a little bit about that box, and what it accomplishes because it seems very important to being able to link the information coming in from a Hirsch PAC device and the NAC element.

Rick Kagan, Infoblox: I can try that one. It is actually a MAP server. MAP is metadata access point. It's not a policy decision point, it's a database. The way we like to think about it is it's almost like Facebook for things on an IP network. It's a way for different devices to publish information about what's going on about themselves or other devices on the network. Just like you can get a Google alert when something changes out in the world and you get an automatic alert telling you that it happened, various systems can subscribe to the MAP database and look for changes in things of interest.
That could be a user authenticating to the network or that a particular employee has badged into the building.  That information is made available to the MAP database. Any device or system interested in knowing, for example, that somebody badges into the building either previously or at that moment, are able to get that information. So it's a way of facilitating the sharing of information by different kinds of systems: a network access control system, a physical access control system and others very, very easily and in a standards-based way.

But the policy decisions are not made by the MAP database. The policy decisions are made by the physical access control system or the network access control system. They are able to coordinate and still do their own jobs but they do it better because they have more information about what's going on. Now, a network access control decision--do I let this guy on my network?--can be informed by [information about whether] he is physically in the building, for example.

SJW: The MAP server--does that only connect to devices or does it also pull information from any software system?

Rick Kagan, Infoblox
: The server is standards-based, and any system that implements the client side of the MAP protocol can put information into the database if it is authorized to do so and get information from the database. Implementing that client, that way of accessing data from the MAP database,e is technically quite straightforward and simple.

Steve Hanna, Juniper: I just wanted to interject two more things about the standard and protocol. All of these companies--Juniper, Hirsch, Infoblox, a lot of others-- are members of a group called the Trusted Computing Group, which is the standards body that created the standard called I-F MAP. Some people call it IF-MAP. That's the standard protocol that is used to communicate with that MAP server.

In addition to implementing it, each device that wants to store or retrieve data from that MAP server database has to be authorized to do so. You don't want to have just anybody able to get the information. It's pretty confidential or it can be security-related information. So we also require that those devices--software, servers--be authorized to access the database.

Bob Beliles, Hirsch Electronics: It might make sense to go up another level. I think it's important to recognize this group of companies that have come together the Trusted Computing Group is reflective of semi conductor companies, data storage companies, network storage companies, virus protection companies, software companies. All of these IT-oriented companies recognized several years ago the importance of protecting data and protecting the devices on the network that either store the data or transmit the data or end up using or manipulating the data. So that's what really spawned the whole concept of 'we need to take into consideration the behavior of certain devices, of what's going on in the network itself in order to protect the network and the devices attached to it.'
 
That spawned a couple of different initiatives within the Trusted Computing Group and one of those ultimately came out more recently was that this development of this protocol, what I would say is the protocol suite. There are more than 100 trusted computing group members that support these standards today. It's not just Juniper, it's Intel, Hirsch, Infoblox, McAfee, Symantec, Boeing...

Steve Hanna, Juniper: Microsoft...

Bob Beliles, Hirsch: So it's a pretty broad and impressive list of vendor companies. All say, 'Yes this is how we are going to do things.' I think there's some significance your readers would be interested in because of course in the physical security industry, standards or standards discussions are only now just evolving.

SJW: I was just about to ask about that. I didn't hear any physical security vendors in that list of companies. Those [physical security] systems are notorious for being closed and difficult to work with even in an open environment.

Bob Beliles, Hirsch: Right. So to your readers the relevance is, here are more than 100 companies, many of them in the IT industry but Hirsch is there, HID, Gemalto, which does smartcard technology, is there. The point is this is a large cross-section of companies that have basically agreed this is the way we think it ought to be done and this is the way we're going to do it with our particular products. There's a lot of support for these kinds of standards. We're basically not sitting here trying to fight against each other, doing it this way versus that way.
 
So pulling it back toward the IF-MAP protocol...What IF-MAP does is enable any device to communicate its status, what's going on, like Twitter or Facebook such that other devices that are authorized to do so can say, 'Based on that information, is there something else I should be doing?'

To our point of physical access to network access interoperability capabilities using the IF-MAP protocol, Hirsch is publishing access control events, authentication of an individual who is now inside the building, and other devices authorized to do so can then take that information, receive it under effectively a subscription basis from the MAP server, then go apply whatever policy they want.

The nice thing is in terms of delineation--and I know some customers can be concerned about where their information is going or is this the physical security world trying to dictate to the network world what's going on or vice versa--the nice thing is all you're doing is saying 'I have some information to share, I'm going to share it with trusted entities or devices,' then it's up to those devices or those other groups that own those devices to decide whether that information is relevant to them and whether they're going to do anything or not.  

So it's not about one world taking over another world, it's about sharing information between the worlds, establishing what I believe convergence is really all about. It's not just connecting different devices on the network and saying you're done, it's sharing information in a trusted and secure way that's going to make IF-MAP very compelling and very useful in a broad number of applications.

<!--nextpage-->

Steve Hanna, Juniper: It's also important in that it's an open standard, so it's vendor neutral. A number of different vendors have implemented this protocol. There's no one vendor who says you have to buy your IF-MAP server from this company or that company. There are multiple companies that offer MAP servers, there are dozens of companies that offer MAP clients that have the ability to publish and retrieve data from that database. So the customers have a lot of choices in terms of vendors and what product they choose.

In some cases, they may already have some of these products in their enterprise and then it's really a matter of 'how can I get more value out of the products I already have installed?' That concept--that I can take an existing product and then get more out of it by plugging it in with other products that I have or that I might acquire through this open standard--not getting tied down to any one particular vendor--that's a really clear win, especially in today's world where we're trying to do more with less and get more out of the equipment we already have.

SJW: I think I get the concept of what the metadata server does, how it publishes information and other trusted, authorized devices who subscribe to it are then able to take the data and they make their independent policy decisions.

What I'm curious about in all of that is managing identities. I looked at Juniper's white paper about its Unified Access Control platform, granting permissions based on [logical] identity and in the physical security world, authenticating an identity and giving it access based on policies is growing too. As I'm looking at this [PAC-MAP server-NAC] architecture, is there a central place for policies to reside? Does each world create its own policies or do they all reside up in an identity management system?

Rick Kagan, Infoblox: Identity management systems are just another source of information. It's a very essential piece of information, and it can be linked to all sorts of other things. That's the beauty of the way IF-MAP works: You are able to aggregate all kinds of information relative to a device and its owner and the policies associated with it.

The way things seem to be evolving, which I think is extremely encouraging, is that there is no single central repository and certainly no enforcement or policy decision point that tries to make all decisions about all things. Existing systems--network access control, physical access control, physical location systems--that would benefit from information about another domain but are hard pressed to get it--because as you said, it's usually in some proprietary format--can now make better, more informed decisions because they can get access to information they couldn't get before and can do it easily in a standards-based environment.

SJW: You're saying people can write better policies now that this information is available, for example, they can know who's actually physically present in the building.

Rick Kagan, Infoblox: Exactly. So folks who have Juniper UAC, unified access control, can now make a policy that says 'I will let this user on the network if he has these credentials and he authenticates, he is in my identity management system--and also if he has badged into the room where my data center is because he's not supposed to access it if he's from outside the data center.' So it just adds another piece of context to make it a better and richer policy decision.

But that doesn't mean we need to move the physical access control decision over to the Junipers or move the network access control decision to the physical access control system. They're still separate.

Moinul Kahn, Juniper:  I am product line manager for Juniper UAC, and I'd like to add a couple more points here. If you look at Juniper UAC, it's role-based access control technology.  Traditionally we would look at your Active Directory or LDAP--basically your central database of user information and user role information is there. So our UAC box will talk to Active Directory or an LDAP to get information about what is the role of the user. Then based on the role, we would create certain policies for that particular user.  So a certain user is logging into the network and we need to protect our engineering server which is located in the data center from this user, we would just push a policy saying this user can connect to XYZ server but not to the engineering server. That's traditional roles-based access.

The IF-MAP server is now allowing us to look at the user, get more information, location-based information, and then create access policies based on that location information. This is just one of the examples of what IF-MAP can bring to the table.

<!--nextpage-->

SJW: When it comes to that all-important business of being able to deprovision users quickly when company employees leave or are fired, and that information needs to be propagated out to network access control elements and physical access control elements, would that information be published through the metadata server or is there a different dataflow?

Steve Hanna, Juniper: Typically that would be kicked off by your identity management system. That's generally the one place that serves as the starting point. Once a particular user's been de-provisioned in the identity management system by marking as terminated, that information can be propagated and received by the physical access control system and/or by network access control, both of which are generally tied into identity management systems.

From there, you can publish that information into the metadata access point. Then all of the other systems tied into the metadata access point would be notified, and the user's physical access and their network access and any other forms of access you could provision would all be terminated simultaneously. That's one of the nice things about having it all tied together through the metadata access point: every [system or device] subscribed into information about that user will be notified immediately as soon a user is deprovisioned.

That will also apply when someone is either promoted or demoted, if their set of rules or group changes. That information can be published into the metadata access point and immediately the level of access that they get can be modified, upgraded or downgraded. Any behavior monitoring systems tied into the metadata access point would change their profile for what behavior is considered normal for that user based on their new updated role.

SJW: The identity management system kicks out the information about whether someone has been terminated, promoted, role has changed. The next step, If I heard you correctly, that data goes into PACS or NACs. So if there is not a connection, then there's a hole.

Rick Kagan, Infoblox: We had a very interesting conversation with a very large company in the Bay area recently. They have a checklist, about 14 steps that have to take place whenever a particular employee is de-provisioned.  Today, they pretty much have to manually go and de-provision that user in a bunch of different systems. It's started off by HR and then they have to touch them in the mail system, the network system, the physical system, etc.

Basically what MAP enables is the automation of that checklist, so that publishing of an event from an HR system to the MAP server saying the status of this employee is now terminated--all of those other systems that would have to be touched, the access control system, the NAC, that subscribe to that can be notified immediately when that employee is terminated and then can execute their own policies. In the case of the PACS, it's 'Don't let them in the door.' In the case of NAC, it's 'Don't let them on the network or have any access to resources.'

Instead of having to manually touch all these things, as long as they are MAP-enabled and authorized, they will automatically get an alert this event has occurred and be able to completely automate the de-provisioning.

Bob Beliles, Hirsch:  It's important to recognize...some of these capabilities actually exist today and are being used by customers.  I can say Hirsch has the ability to pull information in terms of delta changes out of PeopleSoft or an HR database and use that information for accelerating the enrollment of physical access, and we can check for deltas or changes in terms of roles, promotions etc. But it's a painful development effort that many different vendors have had to go through to work with these different databases in a nonstandard way.
 
The real nice thing about the IF-MAP protocol is that here would be a common consistent way that all vendors would have to write effectively just a single application to or open up their API to or have it done in just one way and then you would be able to do this for everybody. That's what makes it really powerful. It would make it a lot easier and I might even argue probably a little bit cheaper for customers as vendors agree on these standards. That's part of the value of standards in general. A lot of these systems [can pull HR information] today; it's just that in many cases it hasn't been using IF-MAP. As IF-MAP is increasingly adopted by more and more companies, we'll see more companies with these capabilities.


# # #

In Part 2, posting next week, we talk more about the value of IF-MAP to overall industry development and convergence efforts, including greater choice at lower cost for customers.

No TrackBacks

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

Leave a comment