This article can also be found in the Premium Editorial Download "Information Security magazine: Improving your network security strategy in a recession."
Download it now to read this article plus other related content.
Price: Starts at $20,000 per appliance
Rohati's new agent-less Transaction Network System takes traditional network access control to the application level to allow complete granular access control
Setup involves a few different steps and resources. The complete system involves configuration of the TNS device, a management server, and possibly VLAN configuration on your switches.
The TNS 100 device we were issued was a 1U appliance that supports up to 4Gbps throughput with up to 256,000 connections. The initial setup utilized a serial console port with simple commands that resemble Cisco IOS syntax. This is useful if you are familiar with this type of command syntax. There are a couple of deployment options here when deploying out-of-band. If you choose not to use VLANs for segmentation, you can simply plug the TNS 100 into a switch and move on to the CMS setup. A little more effort is required for adding VLAN configurations. One of the drawbacks of not using VLANs is that you'll need to configure protected resources to only accept connections from the TNS 100 appliance. This is because the device would accept connection requests from systems other than the TNS 100, in order for the TNS 100 to properly protect the desired resource, you much send all requests through it.
Once the initial appliance setup is complete, you'll need to deploy the Central Management System or CMS to further configure the device. You'll need some server class hardware. Rohati recommends a dual processor 2.0GHz or better, as well as around 120 GB of space and 2 GB of RAM. You can use either Windows Server 2003 SP2 or various flavors of Linux for your host operating system.
The CMS software installation is very straightforward and consists of a single executable delivered via CD. Once installed, you must configure the CMS to talk to the TNS 100 as well as any LDAP system in use.
Policy Control B
Policies are configured via the Web interface over SSL on the CMS server. At the highest levels, Rohati groups everything into policy domains, which are containers for access control points that consist of rules and users. These rules are basically decisions that result in a permit or deny of a request targeted at a protected resource, such as a URL on a Web server.
When building these policies, you can set them in four different ways. An enforcement policy is used to restrict access to resources. A re-authentication policy is used to force additional security even after a successful authentication to a given resource. This would be particularly useful to protect sensitive areas of public sites, such as the administrative panel of the HR online system. A logging policy is a policy that doesn't restrict anything, but allows you to monitor the activity to that resource. This is great if you just need to determine if that resource is being misused and might require further security from the TNS 100 Finally, a simulation policy is used to test policies before they are enforced, allowing you to see what would have been blocked or allowed based on the test rule set. All policies are based on what Rohati calls User Directories, these are basically LDAP repositories such as Active Directory.
Rohati has built a great tool for protecting select resources, however, there are a few factors that may limit the overall effectiveness of this solution. Although the TNS 100 has the ability to utilize default attributes stored in LDAP, it is recommended that you create custom attributes for the purposes of policies. This method is effective, but also time consuming both initially and in long-term maintenance. The sensitivity of the resource will most like determine the level of granularity you choose to use when configuring policies and custom LDAP attributes. Currently there are only two classes of resources supported, websites, and file shares. So if you plan on protecting resources other than HTTP, HTTPS, and SMB, you may run into a hurdle. Rohati, however, has shown they are willing to work through and provide solutions for unique scenarios.
Verdict: Rohati has done a good job in creating an effective solution for wrapping security into systems that may be lacking. This seems a good choice for applications and resources that don't already have great authorization and authentication. Although Rohati is planning a TNS 500 device to be released for in-line deployment later this year, integration may prove difficult in an organization of large size. The TNS 100, however, is a great solution for medium to small businesses that are looking to get an early start on centralized authorization.
Testing methodology: Our lab included two Active Directory domains, the Rohati CMS server, and several SMB resources and Web Servers. Multiple clients were used with each policy definition and resources.
This was first published in February 2009