(Editor's Note: This is a summary of a paper that won the Jericho Forum Challenge at the recent Black Hat event. You can read the full paper ).
The Jericho Forum is all about "de-perimeterization," which involves re-appraising where security controls are positioned. Businesses moving to the Jericho world need to change their thinking away from the "edge" mentality, based on controlled denial of access through firewalls.
Instead, they need to adopt "core" mentality, based on controlled access to servers/applications that would have to be Jericho-ready systems. To achieve anything in the short term, we need to look at the elements involved in the move to a more transactional relationship between users (and their endpoints) and servers/applications. The simplest model has five elements: the user (use cases, identity); the endpoint (security, client software); the communication channel (security); the server (security); and the application (software).
The communication channel is arguably more available than the other elements. To develop a workable approach, we need to explore the issues surrounding the two ends of the transactional relationship. Three models exist at the server/application end:
Jericho-ready systems: Applications that are Jericho-enabled should use Kerberos tickets for authorization to the services, be self-protecting (local firewall) and be prepared to encrypt traffic with SSL, if required by the centrally managed security policy.
Jericho-enabled servers: Older applications require a front end to handle interaction with the Jericho system. This is software that does data encryption and makes sure users are authorized to connect to the application.
Non-Jericho-enabled servers: The simplest solution is to protect the application server with a box in front of it that acts as a firewall, encrypts traffic from users and lets through only authorized traffic.
And three problems need to be addressed from the user end:
Users have no desire (or ability) to remember the details of all the systems to which they want access. It is desirable to have a fixed primary point of interface (PPOI) that understands what a user wants to do.
There must be some identity, authentication and transaction selection functions. This will be associated with the configuration of the server/application end, which permits the user access via Kerberos.
There must be a way of advertising system availability, letting users know what systems are available under the current circumstances.
There is always going to be the need for PPOI. For now, PPOI products have to help with transactional tasks such as encryption for non-Jericho servers. Over time the role of the PPOI will evolve toward control and away from transactional involvement.
Bodley-Scott is regional operations manager U.K. and Ireland for AppGate Network Security. He can be reached at jamie.bodley-scott@appgate.com.