Location vs. Identity: An Example - Pt 1

In a previous entry I described conceptually why it has become necessary to view networked computing through the identity paradigm rather than the more common location based security paradigms. In this entry, we will examine a sampleA classic location based security approach -- create a walled off area of the network and control admission to it. use case to better understand what that means. To avoid having the details of the example itself make understanding the bigger message difficult, we will keep our example simple.

The setup is an enterprise that has two servers running several applications which access and manipulate sensitive information. This enterprise provides its employees with the computers they use in their jobs, and thus is able to configure those computers as required - allowing client participation in the solution if needed. Our goal in part 1 of this example is to create a scenario where the two servers can only be accessed by employees using these company issued computers, but where that access is possible from any point on the global internet. We also wish to report any attempts to access the servers by any other computers on the internet.

This is a relatively simple scenario, easy to conceptually understand, and the sort of policy it is easy to imagine a company desiring. But as we approach providing this outcome using traditional location paradigm security methods, we quickly see it will take several components to accomplish. We might first try to put the servers on a sub-net with a firewall between it and the rest of the network. This is a classic location based security approach -- create a walled off area of the network and control admission to it, rejecting all but approved access.

A firewall works with network level information such as IP addresses, MAC addresses, protocol types, ports, etc. This isn't very directly related to whether the connecting computing was issued by the company or is being used by an employee, but many ACLs later, with a great deal of effort and analysis of the network, the problem will be partially solved. The next move might be to add a proxy server, or possibly VPN capability and require user authentication to cross the firewalled boundary to access our protected servers. Overlooking the downside that this adds yet another authentication point to our network, it does allow us to assure that only those who know the secret handshake can access our protected servers.

Combining "authenticated bridges" (e.g. VPNs or application proxies) with the firewall gets us close to solving our problem. However we are still attempting to approximate what we really wanted by using combinations of network location and shared secrets that really don't directly relate to what we want to know. Adding intrusion detect to report unwanted access attempts will yield many alerts that will have to be painstakingly analyzed to know what is really going on, but finally we are approaching meeting the mission.

This simple example of two servers with sensitive applications is already illustrating many of the limitations of traditional network-only level or application-only level approaches. These limitations result because those approaches use constructs that are not truly related to what the policy revolves around - identity.

So what would a truly identity based approach to this simple to state, but surprisingly difficult to implement scenario look like? One approach is to use a product like the I-gateway from Trusted Network Technologies that bridges identity and network level constructs. TNT's approach steganographically imbeds identity information into fully RFC compliant TCP/IP packets. This means that those packets, when looked at by traditional network software and hardware, will be handled as expected. But if those packets are examined by identity aware software or hardware (such as the I-gateway), the identity information can be extracted and decisions made based on it. This does require installation of client software to embed the identity data, but our scenario allows that (and we would likely do that for the VPN above as well.)

If we then connect the I-gateway to our Active Directory or LDAP authentication identity store, we can use the existing user network authentication transparently to decide if a connection to our servers should be allowed or not. And any connection that either lacks embedded identity information in its TCP/IP packets, or where that information doesn't authenticate to our identity store, can be classified as an unauthorized access attempt immediately.

By viewing the problem from an identity perspective, we are able to add one device/application (vs. as many as three in the location based paradigm) and that device is addressing the problem directly on the level it was stated - allow access from those people using the computers we gave them, let no one else in, and log any other attempts to access the servers. Our reports correlate directly with the problem as stated, providing identity based information directly (rather than IP addresses, MAC addresses, etc.) and follow any dynamic network nature such as DHCP etc. without requiring translation and analysis of those logs to know what they really mean is happening.

But as we'll see in part 2 of this example, having converted to viewing the problem through the identity paradigm, we not only become able to solve the original problem far more easily and cleanly, but we open up the ability to address many more business based requests for management of the situation as well.