Integrated Secure Communications System

The ISCS (Integrated Secure Communications System) is designed to address one of the most pressing yet understated needs in enterprise, multi-partner collaborative, mobile, wireless or multi-client service security - containing the cost of security management. Year after year, we live with the fact that 70% of our data security breaches are from within. We know the problem will only exacerbate as the lower cost of connectivity brings more small and physically insecure offices onto the corporate WAN and as hand held and embedded computing devices become more common. We know that simple and easy data sharing between business partners is very healthy for corporate objectives but we cringe at the security implications. Why do we live with these problems and do so little about them?

It is not for lack of tools. Plenty of products from firewalls to VPN's to Intrusion Detection Systems to content filtering exist to implement the security we need to meet these issues. The problem is not the technology; it is the implementation of the technology -- specifically the complexity and cost of managing such granular security. So what are we going to do about it?

ISCS reduces the cost of managing complex security by 90%. That grandiose a statement should turn some heads. If we can implement sophisticated security for less than 10% of its current cost, we can afford to implement stringent inter-office security so that a tiny branch office that accounts for 0.1% of revenue cannot be the access point for a WAN based data attack against a hub office that generates 45% of revenue. We can say, "Yes," to business units when they want to increase data sharing with their external business partners. We can safely create multi-client service delivery infrastructures with shared facilities without sleepless nights worrying if Client A can compromise Client B's data. We can affordably and efficiently sandbox mobile, hand held and wireless computing devices to minimize the impact of physical theft, identity theft or security compromise. We can create a multi-layered internal security model that effectively contains phishing, spam and trojan exploits without undo financial and administrative burden.

The 90% security management cost reduction is not a projection; it is based upon production data for existing installations of the proprietary, conceptual forerunner of the open-source ISCS. To be fair, the entire cost of administration is not security management. There are still system upgrades, hardware failures, physical installation, planning and troubleshooting. Those are not reduced 90% but the cost of creating and implementing security policies is. This product has not been designed by speculation. It is based upon real world deployment.

The underlying concept of ISCS is to automate the creation of security device specific rules. This frees the security administrator from the need to know the details of each device and from manually configuring the rules on each device. The reduced time needed to implement security policies allows the more sophisticated security required by contemporary environments to be cost-effectively deployed. We can finally do something to reduce the 70% of data compromises that are internal. We can finally easily facilitate business partner connectivity. We can finally safely operate shared, multi-client infrastructures. We can finally integrate hand held, wireless and embedded computing devices into our business processes without constant fear of a security catastrophe.

Traditional security products cannot scale to the number of rules and, most importantly, the rate of change of the rules necessary to cost effectively manage this sophisticated security. If the security environment cannot be easily managed, it will not be secure no matter how good the underlying technology is. Manually created, order dependent access rules, complex security associations and other forms of manual security subsystem administration are far too labor intensive and prone to human error for such a constantly and rapidly changing environment. Thus even the most advanced network security management tools are entirely inadequate for contemporary security needs and will be as long as they rely upon manual rule creation and configuration.

The ability to quickly create, change and distribute security configurations in a distributed environment -- the ability to cope with change is the key differentiator for ISCS.

HOW IT WORKS:

To repeat, manually created rules and configurations are far too labor intensive and prone to human error for a constantly and rapidly changing environment. Thus even the most advanced network security management tools are entirely inadequate for contemporary security needs and will be as long as they rely upon manual processes.

This need to accommodate constant and rapid change is a major reason why inter-office security is rarely implemented, partner connectivity is a nightmare, why multi-client providers endure the expense of duplicate, independent infrastructures and why we cringe at the thought of executives and sales staff using their mobile phones and PDAs for data access. ISCS removes these barriers by dramatically reducing the cost of security configuration.

ISCS achieves this breathtaking cost reduction by insulating the security administrator from device rule creation. The security administrator creates high level, business function oriented policies such as "Sales has access to Sales data", "Executive and Financial have access to Financial data" or "Project A Engineers and Partner Company B Project A Engineers have access to Project A data." The reduced opportunity for human error in the configuration and rule creation process additionally increases the overall security of the environment.

These high level policies are then translated by ISCS (specifically the SPM discussed below) into potentially hundreds or thousands of device specific rules and automatically distributed to the devices that enforce those rules. VPN tunnels are automatically created where needed, user authentication and access control is enforced, NAT is implemented, proxy ARPs created, certificates managed, routes created and, in the near future, intrusion detection/prevention, anti-virus and content filtering rules are distributed. The security administrator never has to touch a single device or write a single device specific rule. In fact, ISCS allows the administration of a multi-vendor security environment without requiring vendor and device specific knowledge on the part of the day-to-day administrator. As long as the vendor's device can talk to the SPM, all configuration looks the same to the administrator. The security administrator lives in a world of policies rather than devices.

Architecture:

ISCS operates at the network layer. Although its decision criteria may involve information up to the application layer, the ultimate function of ISCS is to allow or deny a data packet. ISCS has three functional components, namely, PEPs (Policy Enforcement Points), the DBD (DataBase Distributor) and SPMs (Security Policy Managers).

PEPs are the physical gateways that make the decision to allow or deny a packet. They are very similar to gateways from traditional vendors. The current incarnation supports Linux based PEPs but the architecture is entirely modular. As long as the device can provide the needed functionality, ISCS can be adapted to use any enforcement device regardless of hardware or software platform. The PEPs have both an out-of-band communications route to the DBD.

The DBD is responsible for storing the SQL database which describes the security environment and for distributing the changes to the PEPs. The DBD is designed to run on virtually any RDBMS. Where there may be thousands of PEPs and many SPMs in a large ISCS environment, there is only one DBD.

The SPM is the brains and magic of ISCS. It is currently a Linux based X application but is developed in C++ using Trolltech's Qt toolkit with an eye to easily porting it to Windows and Macintosh. It creates the device rules based upon highly abstracted, business level policies as well as managing the PEP configuration. Phrased another way, the SPM performs two principle functions -- element management and security policy management.

As an element manager, the SPM is quite similar to the best "policy enabled" management consoles of traditional security device vendors. In their vocabulary, "policy enabled" means centralized element management. As such, the SPM enables the automatic creation of VPN SAs, full integration with its PKI (creating an interesting potential solution for PKI enabling legacy applications without rewriting legacy code), the automatic distribution of rules to the PEPs and the ability to remotely install, configure or repair a PEP. The only major difference from the better available element managers is its vendor independence.

However, it is the SPM's ability to create device level rules from high level policies in an extraordinarily efficient manner that is unique to the industry. This is what we mean by "security policy management."

The SPM difference is manifold yet elegantly simple.

ISCS is a very rich product but to best illustrate how it is unique, we will focus on access control. The same principles can be applied to other aspects of security management. The SPM's extraordinary efficiency is achieved through the following:

1. Separate the processing of WHO, ACCESS and WHAT in the question "WHO has ACCESS to WHAT."

2. Allow many different means of user identification (IP address, X.509 certificate, browser certificate, NDS, Active Directory, NT Domain, LDAP, RADIUS, SecureID Token) to be included in the same user group (an Access Group in SPM terminology).

3. Organize Access Groups in a hierarchical structure with inheritance.

4. Combine the server and service, i.e., destination address and destination protocol, into a single composite object -- a Resource in SPM terminology. Organize Resources with similar access needs into Resource Groups.

5. Organize Resource Groups in a hierarchical structure with inheritance.

6. Create policies by defining relationships between the Access Group and Resource Group hierarchies.

7. Manipulate the relationships through an easy to use, drag and drop GUI.

WHO has ACCESS to WHAT?

This is the classic access control question. Traditional access control mechanisms such as firewalls answer this question in a monolithically with a rule syntax such as:

Given Source Address A on Source Port B trying to access Destination Address C on Destination Port D, take action E.

The more sophisticated systems may allow for user identification beyond just IP address and port so their syntax might be:

Given User A trying to access Destination Address B on Destination Port D, take action E.

Because it is monolithic, i.e., the question is answered in a single statement, the security administrator must create a rule for every needed combination of user (Accessor in SPM terminology) and destination (Resource in SPM terminology). ISCS answers these questions separately. First it processes a rule to determine who the Accessor is. Then it processes a rule to ask what kind of access the Accessor is requesting. Then it finally processes a rule to determine what resource is being requested.

On the surface, the modular approach seems more complicated. In practical application, it is much simpler. First, ISCS only has to define its Accessors and Resources once. It can then mix and match its predefined Accessors and Resources to answer the questions. High reuse with corresponding greater efficiency is the traditional advantage of modularity. Second, the separate processing creates a natural sort order for the rules. Instead of potentially having to traverse the entire rule set to evaluate a packet, the ISCS PEP only has to traverse the rules that apply to the Accessor and then only those that apply to the type of Access. This allows for a far greater number of rules on an enforcement device without significant performance degradation -- the number of rules necessary for sophisticated, granular security.

Combine different types of Accessors into the same Access Groups to minimize the number of security policies

The benefit of this principle is reducing the number of policies that the security administrator must define. In a rules based system, the security administrator would likely need to configure a separate rule for each type of user and that assumes that the enforcement device has the ability to identify users by more than IP address. In the SPM, we combine users of any type based upon identical access needs. We can then create a single policy for the Access Group that will apply to all the different types of user identities rather than a separate policy for each. Again, our goal is to write as few policies as possible. We can let the SPM then go ahead and create the rules that are specific to each different type of user identity whether it is IP address, X.509 certificate, Active Directory, LDAP, e-Directory, RADIUS, SecureID, etc. The computer does the work. The security administrator never has to be bothered. He merely says, "The entire company has access to Human Resource employee policies." He does not have to bother himself with how "The entire company" is identified -- at least not when he creates the policy.

Organize Access Groups into a hierarchical structure with inheritance to minimize the number of security policies

This principle is also targeted at minimizing the number of policies needed to create the needed security. Our business processes naturally fall into hierarchies. They may be shallow or deep. They may be geographic or functional but we will find hierarchies. When a right is granted to an Access Group in the SPM, all Access Groups below it in the hierarchy inherit the same rights. This eliminates the need to explicitly create policies for all the descendant Access Groups.

Thus there is great flexibility in how we can create user access policies. Some data needs to be accessed by a very specific group of users. Rights can be granted to just that one, low-level of users. Other data may need to be accessed by the entire organization. Instead of needing to create a policy for every single organizational unit in the enterprise, the security administrator can simply grant the right at the top of the enterprise tree.

The efficiency gains are enormous. Eventually, the individual, device specific rules must be created for each user definition but the SPM, the computer, does that. The security administrator does not. She simply grants the high level right in a single policy. Imagine a large, multi-client service provider. Perhaps they want to grant everyone in all of their 10,000 customers access to the customer interface of the trouble ticketing systems to check the current status of their own trouble tickets. The access can be granted to the entire customer base by granting the right at the top of the client tree. That single drag and drop operation may produce 100,000 rules that need to be distributed to 50,000 devices but it took the security administrator literally five seconds to drag the "All Clients" Access Group onto the "Public Services" Resource Group. The SPM will handle creating and distributing the device specific rules. The computer is far less expensive than the security administrator and less prone to human error.

Combine server and service into a single Resource object to minimize the number of security policies

This is a subtle but very important principle to minimize the number of policies that need to be created. Some vendors such as Solsoft, SmartPipes, Evidian and NetScreen have made initial attempts at security policy management but all of them fell into this trap and will require a major recoding effort to extract themselves.

The few who have attempted this kind of organization allow the security administrator to create a group of servers and a separate group of services. She can then grant users rights to that group of servers and that group of services. The problem is that such a policy grants rights to all the services within the service group on all the servers within the server group. That is still pretty cryptic. Let's illustrate with an example.

Let's say that our security administrator has three Windows servers (A, B and C) that the Facilities department needs to access. Facilities specifically needs access to the http service on A, file & print on B and ftp on C. Of course, it just so happens that server A also has file & print and ftp services for the administrators to use. Server C has file & print for the same reasons. Server B just happens to have a web server running to administer an application for the Sales department that happens to be running on the same server as the Facilities file & print (it saved Sales the cost of buying another server and the Facilities file & print server was lightly used anyway).

Our security administrator creates the server group "Facilities Servers" and adds servers A, B and C to it. She then creates the service group "Facilities Services" and adds http, netbios (file & print) and ftp to it. She now creates a monolithic, device level rule that says:

If "Facilities" tries to access "Facilities Servers" on "Facilities Services", allow the packet.

If we analyze that rule, we will quake in security horror. As well as the intended rights, we have just given Facilities access to the file & print and ftp services used to administer Server A and the file & print services used to administer Server C as well as access to the Web based management console for the Sales application on Server B! This is not at all what the security administrator intended.

To not create such a security nightmare, our security administrator will have to create three separate monolithic rules -- one to give http rights to Server A, one to give file & print rights to Server B and one to give ftp rights to Server C.

Contrast this to the SPM. The security administrator first creates a Resource Group called "Facilities Data" and next creates a single policy to grant "Facilities" access to "Facilities Data." To grant access to http on Server A, she merely adds the object for http on Server A to the Facilities Data group. She does not even have to create a new policy. She drags the netbios (File & Print) services for Server B into the Facilities Data group and the ftp services for Server C. If Facilities adds another service, there is still no need for an additional policy -- just add the new server/service object (Resource) into the Facilities Data Resource Group.

Organize Resource Groups in a hierarchical structure with inheritance to minimize the number of security policies

This is the same concept as organizing Access Groups into a hierarchical structure with inheritance. If the security administrator grants rights to a Resource Group to an Access Group, the Access Group also receives rights to all the Resource Groups below that Resource Group. For example, one might have a superuser administrators group that has access to everything. That group can be given rights at the top of the Resource Group tree and there is then no need to further define policies for each of the subgroups. The superuser group will automatically have rights to the rest of the tree. On the other hand, a high level Access Group such as "Entire Company" might be given access to a low-level Resource Group such as "Company Forms."

Create policies by defining relationships between the Access Group and Resource Group hierarchies

This is where everything comes brilliantly together. As already described above, creating a security policy is as simple as dragging a Resource Group onto an Access Group or vice versa. The SPM creates all the device specific rules, links the modular WHO rules with the modular ACCESS rules with the modular WHAT rules and distributes those device rules to all the PEPs. A five second drag and drop replaces hours, perhaps even days of security administration.

Imagine what this kind of efficiency could mean to a carrier offering a managed secure communications service - CPE IPSec security with the management overhead of MPLS and the added customer value of inter-office security. Imagine what it could mean to a multi-client service provider trying to deliver its remote services inexpensively yet securely to client sites. Imagine what it means to enterprises if they can limit user access to data to what users need and respond quickly to those changing needs -- they can finally start to do something about those 70% of data compromises that are internal. Imagine what such responsiveness to change would mean during a merger or acquisition or in the creation of a partner Extranet.

Manipulate the relationships through an easy to use, drag and drop GUI

The SPM is a perfect application for a GUI. Complex relationship are best understood and manipulated visually. The SPM GUI has been designed by the same security administrators who used the previous proprietary system for four years. It incorporates what they have learned through practical field use.

REAL WORLD COMPARISONS

Our estimates of a 90% reduction in the time to administer security devices in ISCS is based upon our real world experiences. Please remember that not all of a security administrator's time is spent administering security policies. Other activities such as physical installation, planning and executing upgrades are going to be similar to other products. But, when it does come time to administer security policies, a 90% savings is a conservative estimate.

Here is a sample scenario based upon an actual comparison between how we would approach a situation with ISCS and how we would have to approach the same situation with one of the existing vendors. This is from a real discussion with the NetScreen sales team for our area.

The initial scenario is that we have 200 offices. We have Sales staff in all 200 offices. We are taking advantage of our position as a global company by connecting ourselves as a global company with an Internet based VPN. Because we are aware of the security implications of such a move, we are implementing inter-office security. All the Sales staff need to connect to a database in New York. We have not implemented PKI and user certificates so we will identify Sales users by allocated IP addresses.

To do this with NetScreen (at least using the management console that was presented to us by the NetScreen sales people), we would need to create 200 order dependent rules -- one for each IP address range to allow them access to the database service in New York.

Let's assume that a blindingly good security administrator can create one of these rules and determine in which order to place it in 30 seconds. That is a very aggressive number. 200 rules times 30 seconds per rule is 6000 seconds or 100 minutes.

The ISCS process is a little more involved. The security administrator does not have to create monolithic order dependent rules. Instead, he creates a Sales Access Group and a Sales Data Resource Group. He then makes a list of 200 IP addresses (far simpler than creating a source address, source port, destination address, destination port, action rule). He adds one entry for the database service on the New York server to the Sales Data Resource Group. Finally, he drags the Sales Access Group onto the Sales Data Resource Group. That sounds like much more work but let's look at the numbers.

We'll pretend our security administrator is suffering from a massive headache and has arthritic fingers. Thus it will take him ten seconds to add an IP address to the list and one minute to create each Group and Policy. Two Groups and one Policy = 3 x 1 minutes or 3 minutes. 200 items listed at 10 seconds each = 2000 seconds or 33 minutes for a total of 36 minutes. A sizable reduction from 100 minutes and that with a hangover! But it is still not a 90% reduction. Watch what happens next.

Our new globalization strategy has succeeded and Sales is expanding. We have now added a web service in Paris, file & print servers in London and Chicago and another database server in Hong Kong.

Our traditional security administrator needs to add 800 more rules. One rule for each of the new servers for each of the 200 offices. But he is a very good administrator and can add them all in just the right order with no typographical errors and no human errors and can do all 800 at the rate of one every thirty seconds. 800 rules x 30 seconds per rule = 24,000 seconds or 400 minutes or almost seven hours.

Life is much simpler for our suffering ISCS security administrator. Since the Sales Access Group, Sales Data Resource Groups and the policy giving one access to the other are already created, he merely needs to add the four additional services to the Sales Data Resource Group by dragging and dropping them in on the GUI and clicking on the "Commit Changes" button. He is rather slow this morning from his headache and arthritis so each drag and drop operation takes him 10 seconds. The total time to add the four new Sales Resources is 40 seconds as opposed to seven hours. Well . . . that is really not fair. The ISCS administrator does need to create the definition for the server and resource. That takes the traditional administrator 30 seconds so it will take our impaired ISCS administrator one minute. This increases our total time to four minutes and 40 seconds - roughly a 99% reduction in administrative overhead.

HISTORY:

In 1999, Nexus Management, a global IT Service Outsourcing company targeting international SMEs, decided to radically alter its service delivery method. Nexus felt it could add more value by minimizing the number of service delivery personnel on site and delivering systems & network monitoring, systems & network remediation, remote control help desk, desktop asset, configuration and software management, security management and project planning & engineering from follow-the-sun Global Network Operations Centers in the Americas, EMEA and APAC. The service delivery team would also include engineers scattered throughout the world working from home or client sites -- a physical as well as virtual centralization that would fully exploit the trend toward globalization.

ISCS enables the virtual enterprise.

Nexus found that its needs were almost identical to those of its enterprise customers. Nexus needed ubiquitous, inexpensive connectivity. A T3 line might be justified to the 10,000 person headquarters in New York but even a fractional T1 was not justified into the seven person outpost in Bangkok. This was not the only issue.

ISCS provides VPN

ISCS provides user authentication and access control

ISCS provides inter-office security

Nexus needed security between its GNOCs and its client sites. The data needed to be protected in transmission thus requiring a VPN. The clients needed to be assured that Nexus staff would only have access to what they needed to access. Nexus needed to be sure that any client systems connecting to the Nexus GNOCs only had access to the systems and services they needed and that one client could not use the Nexus GNOCs to relay into another client's systems. This required the user authentication and access controls of a sophisticated firewall.

This was neatly analogous to Nexus' clients' need for inter-office security. Nexus' clients should be able to limit user access across the WAN to only those services they need. Someone who has disguised themselves as the local repairman and walked into the server room of the ten person office in Bogota should not be able to launch a denial of service attack against the servers at the corporate headquarters in London. An ordinary user in Bahrain should not be able to send packets for host administration functions to the database server in Hong Kong. Users need to be identified and their access restricted to what their identity entitles them.

ISCS provides intra-office security

Nexus also needed to address user security within its GNOCs. It should not be possible for a visitor to plug in their laptop to a convenient wall jack and suddenly have access to all of Nexus' clients' systems. It should also not be possible for them to access Nexus internal systems or to capture clear text traffic from the network. Thus Nexus needed the same VPN, user authentication and access control on the LAN as the WAN with the additional need of wire speed throughput.

ISCS provides inter-company security

Nexus additionally had the need for its engineers on one client site to access systems on a different client site. This is directly analogous to a corporate need to allow some but not all people at a partner site to access a restricted set of data resources on the internal network. This required the data to be tunneled while traversing the partner's internal network as well as sophisticated user authentication and access control.

ISCS provides distributed security

Nexus clients had an additional need to move Internet access security enforcement policies out to the branch offices. Nexus found that for many clients the principle WAN bandwidth usage was not mission critical applications but Internet traffic that needed to be hauled across the WAN to the corporate firewall which, in turn, sent the responses back over the WAN to the branch office. Nexus needed a way to centrally create Internet security policies and distribute them to branch office security enforcement points.

Traditional VPN/Firewall products cannot scale to the number of rules and, most importantly, the rate of change of the rules necessary to cost effectively manage such sophisticated security. If the security environment cannot be easily managed, it will not be secure no matter how good the underlying technology is.

Nexus initially thought the answer would be to use VPNs through the Internet to provide the requisite connectivity. After investigating virtually every VPN vendor available in 1999, Nexus concluded the changing security needs of a global, collaborative market place had stood the world of VPNs and firewalls on its head and the vendors had not yet fully realized the implications of the shift.

The use of the Internet for connectivity meant that instead of 300 offices with three Internet access points, the enterprise would now have 300 offices with 300 Internet access points. How would one manage the Internet security policies for 300 gateways? That problem was trivial compared a more subtle implied issue. With 300 potential points of compromise, the old "hard and crunchy outside but soft and chewy inside" security model, i.e., a fortress perimeter at the Internet access points with a wide open WAN, was no longer safe. In reality, it never was safe -- that is why 70% of data compromises are internal! The problem has only grown worse with telecommuters, mobile workers, hand held, embedded and wireless computing devices.

The low cost of connectivity opened the door to bring previously isolated branch offices onto the WAN. This, again, greatly increases the need for inter-office security. Physical security may be impregnable at corporate headquarters in San Francisco but what is it like in Backwater Flats? A wide open WAN means that the systems are only as safe as the security in the weakest office.

Implementing inter-office access control is an entirely different matter from Internet access control. Traditional firewalls are relatively static. Basic services are let out to virtually all Internet hosts and, occasionally, inbound services are opened for public servers. With inter-office access control, every time a new server is added, every time a new service is added to an existing host, every time a new office opens and every time a new user community is defined there is a change to the security configuration. It is the difference between a few changes per quarter and many changes per day.

The problem is made even worse when inter-company collaboration is added. In that scenario, security changes are provoked with each new partner, each loss of a partner and each expansion or contraction of the scope of collaboration. Changes to partner security must be implemented immediately and not queued for processing. Manually created, order dependent access rules are far too labor intensive and prone to human error for such a constantly and rapidly changing environment.

Nexus needed to find a solution that addressed all these issues. The solution needed low cost of acquisition, deployment and maintenance. The Internet allowed for low cost, high bandwidth, ubiquitous connectivity but the cost of managing security with traditional, manual security products would easily negate any savings and intolerably inflate the cost of the proposed remote support model. Nexus did find a solution but there were problems.

WHY OPEN SOURCE?

The Open-Source model frees us from vendor vicissitudes

Nexus reviewed virtually all VPN vendors available in 1999. All were eliminated in the first review because of their inability to be cost-effectively managed except for Nortel, Checkpoint, Cisco and a little US West Coast startup company. After extensive review, Nortel, Checkpoint and Cisco still proved to have too high a cost of management. Nexus swallowed hard and chose the startup because they had such a revolutionary product - the only one that even came close to meeting the specified needs. Nexus also knew that the small company was in financial difficulty.

Nexus endured six months of the startup not being able to take the product forward until they finally were acquired by another company. That company had no idea of the power of what they purchased so Nexus invested another six months helping them see the potential of the product. Just when Nexus thought the new company was ready to bring the product forward, they also stumbled financially . They sold the rights for the product back to the original venture capitalist who buried the product. The new company was subsequently themselves bought by a third company.

Now stranded with core infrastructure built on an unsupported product, Nexus attempted to find an existing vendor who would not be blinded by "not-invented-here" syndrome and consider using the Security Policy Management paradigm. They were delighted when a major security vendor expressed an interest. The vendor was stunned when they saw what Nexus was able to do and committed to building the next generation of their VPN appliances around the Nexus management model. Nexus expected shipping product in seven months. However, the company seemed internally torn about its appliance business and, after a year of waiting, Nexus was told that the new company was backing out of the VPN appliance business. Nexus had now endured two years of being held hostage by vendor circumstances outside of its control.

However, during those two long years, something radically changed the IT landscape -- the rise of Open-Source development. Nexus had considered self-development of a solution but rightly perceived that they were not a software development company. The needs of the product were huge - VPN gateway, VPN client, firewall, proxies, Certificate Authority, Intrusion Detection, Content Filtering, Anti-Virus, router, policy manager. There was no way Nexus could tackle it all even though it had discovered a truly non-linear innovation in the marketplace . . . that is, not until Open-Source.

After the final vendor debacle, Nexus looked around and realized that virtually everything it needed was available freely and widely supported in the Open-Source world. There were even ready made appliances running all the software Nexus would need. The only missing pieces were the policy manager and the glue to tie the policy manager to the PEPs.

The Open-Source development model allows higher quality at a lower cost for companies whose primary function is not software development

Nexus felt it could write enough of the policy manager to make it functional, release it under GPL to the Open-Source community and then try to build a community of other organizations who would have an interest in the advancement of ISCS. The Nexus goal was not to make a fortune from selling ISCS but to derive revenue through the delivery of IT services over the infrastructure created by ISCS.

By banding together multiple companies with a need for secure communications management, Nexus could forge a larger and more varied development team than it could ever afford on its own. The cost of development is divided among many and the variety should lead to a more balanced, higher quality product. It is more important that ISCS deliver Nexus services well than that Nexus make money from ISCS.

The SPM is only a small piece of the picture. The quality of the firewall, VPN, Certificate Authority, router and all the other components needed for ISCS is certainly greater and derived from a vastly larger development team than Nexus could ever field.

The Open-Source development model insulates other contributors from Nexus

To be fair to the rest of the contributors to ISCS, ISCS needs to be able to stand independently from Nexus. The Open-Source model means that those who have invested in ISCS are not left exposed should anything ever happen to Nexus. Unlike proprietary solutions, the end of the vendor does not mean the end of the product or even support for the product.

An Open-Source solution gives us innumerable platform options

The selection of Linux as the first PEP OS opens the door to an incredible variety of potential PEPs to meet every conceivable client need. There are sub-$200 Linux security devices from companies like SnapGear that can be used as personal security devices. On the other extreme, there are devices from companies like Bivio and Arkoon that can pass encrypted traffic at Gigabit wire speeds. One can even choose to create one's own appliances.

FINAL THOUGHTS

ISCS was original envisioned as a service delivery mechanism for Nexus. However, it is such a radical improvement to the world of secure communications that Nexus Management has released it to the Open Source community to foster its widespread adoption and further development outside of Nexus under the independent auspices of the Open Source Development Corporation.

The potential uses are numerous. Service providers like Nexus can use it to reduce the cost of service delivery. Carriers can use it to provide sophisticated security services to their clients at a minimal cost. Enterprises can use it to finally do something about the problem of securing internal communications. Security vendors can ISCS enable their products to create a tangible differentiator in an increasingly commoditized market.

There are surely some less direct uses as well. An obvious use is enhancing the security of legacy applications. By shifting some of the user authentication responsibilities from the application layer to the network layer, legacy applications protected by ISCS can use its strong user authentication features to enhance their own security. For example, there has been much talk of the desire to PKI enable legacy applications but the expense if modifying the legacy code is prohibitive. If such a legacy application is protected by ISCS, a user may be required to first authenticate with their digital certificate before they can send a packet to the legacy application. From the user's perspective and from a practical perspective, the application is PKI enabled for initial access -- the end users cannot use it unless they can furnish a valid digital certificate. However, from the perspective of the legacy application, nothing has changed. It is oblivious to the implementation of PKI to enhance security.

In conclusion, ISCS automates the creation of low-level device based rules and configurations through the use of high-level, business function oriented policies. The result is vendor and device transparency to the security administrator and reduction of over 90% in the cost of managing security. The massive cost reduction and ease of management imply better quality and more extensive deployment and use of existing security tools. The ability to rapidly and inexpensively respond to changing security needs allows internal data communications to be secured, easier accommodation of data sharing with business partners, secure sharing of infrastructure in multi-client environments and the ability to secure mobile, hand held and wireless devices. ISCS warrants the attention and support of the communications security community.