Full Enterprise
Security Demands DCE

By Jonathan Chinitz
President and Founder
IntelliSoft Corp.

Managers everywhere are trying to move from first generation client/server to enterprise-wide distributed computing, with dozens or hundreds of shared services on the network. Most of them are giving serious attention to the OSF Distributed Computing Environment (DCE) technology and see the benefits of using it as an integrating framework. At the same time, they're exhausted trying to keep up with new Internet technology, much of which breaks the client/server paradigm they've just gotten used to. They're frustrated trying to understand possible migration paths to technologies like CORBA and DCOM/OLE, when the specification of those technologies is in many ways still vague. They're agonizing over whether to move to Novell NDS or scrap their Novell infrastructure entirely for one based on Windows/NT server technology. They would like to believe in industry standards and open systems, but fear that they're going to end up dominated by "a single vendor." They know they need to do something now to stabilize and automate enterprise resource management and drive down the cost of desktop support by an order of magnitude.

More than any of this, they're worried about distributed system security. The corporate offices in most firms have woken up to the tremendous exposure they face from unsecured systems and networks. As they push to further automate their businesses and put more and more critical activity in harm's way, top management is demanding a plan and a timetable for the rollout of effective security measures.

Most IT managers are keenly aware that they need more than just the secure authentication capabilities being touted by the 101 companies offering Internet security solutions. They also need all of the following: data integrity, to protect data on the wire against tampering; data privacy to protect against theft or misuse of information; and non-repudiation, to provide the irrevocability necessary for electronic commerce. But more essential than any of these is an authorization capability to stipulate who's allowed to invoke which operations and on what data. Authorization is also known as access control. It should be obvious why it's so important - without it, anyone who gets onto an enterprise network can see and do whatever they want. This is precisely the area where DCE shines the brightest. Mutual authentication, data protection services and a scalable authorization model are at the foundation of the DCE security infrastructure. And with the public key integration work being done today at the OSF, the aspects of non-repudiation and off-line authentication will quickly become an integral part of the DCE framework.

Most companies implement access control on a case-by-case basis, inside of sensitive applications. This is costly, complicated, unmanageable and not very secure. What's needed is an access control infrastructure that extends its umbrella of entitlements and restrictions over all users and resources in an enterprise, irrespective of application, programming, language or operating system. Such an infrastructure must be tightly integrated with the rest of the distributed system security framework. Again, we have found no better infrastructure that meets these requirements than DCE. Security has to be end-to-end, with an unbreakable chain of trust extending from an initiating client to each of the services invoked in a distributed operation. The access control infrastructure must protect not only new applications that are built with an awareness of its existence, but also legacy applications written and delivered before access control was ever raised as a concern.

Experience also shows that you've got to deliver all this in a way that is non-intrusive, so that users and application developers hardly know it's there - except when they try to do something that's prohibited. Security should be flexible, allowing for the definition of new access rules after an application has been delivered. This implies that security should be implemented administratively, not programmatically, or, to put it another way - security should not be "hardcoded" inside the application.

It's clear that the universal acceptance of DCE is contingent on its successful integration with other software - including commercial off-the-shelf packages like Peoplesoft, Foxpro, Sybase, Oracle, or Lotus Notes and also including one-off customer-written applications. IT managers have continued to tell us this. They want a magic product with which they can bring all elements of their legacy environments under the DCE security umbrella, including hundreds of custom-built applications, but also including standard TCP/IP applications like telnet, ftp, mail, news, network management and network file systems. They have a vast infrastructure of client/server applications, all communicating over the same network, none of which share the same security model, many of which have no security framework at all.

DCE/Snare(TM) brings the power of the DCE security infrastructure to any and all TCP/IP-based applications with complete and total transparency. It is a breakthrough technology that marries the established practice of protocol tunneling with an adaptive authorization architecture. Like other DCE-based tunneling products, DCE/Snare can protect any application data that uses well known ports by encapsulating it inside of secure DCE RPCs. The tunneling is performed through a proxy process (DCE/Snare Manager) and is completely transparent to the applications involved. DCE/Snare differs from many other tunneling products, though, because part of it (DCE/Snare Driver) operates at the network driver layer, making it independent of application-layer protocols like HTTP, TELNET, ODBC or SQL. This allows DCE/Snare to act as a machine's "private firewall," securing all network traffic to and from that machine.

DCE/Snare is designed and delivered with the needs of the IT manager in mind. It comes complete with a GUI-based management environment (DCE/Snare Console) that allows for secure remote management of any node in an enterprise network. The management console maintains a centralized database of service rules and object rules.

The service rules control the protocol security attributes (e.g. encryption level, auditing requirements, location constraints), while the object rules control access to the protocol resources. These databases are distributed to each and every DCE/Snare node automatically. This rule-based security model is at the heart of DCE/Snare's Adaptive Security Framework (ASF). The ASF allows DCE/Snare to quickly and seamlessly adapt its security and access control model to the semantics of each application and the requirements of the organization.

For example, organizations that do not want to allow outbound telnet services from any or all machines can create a default rule that will be applied whenever a telnet connection is attempted. The same goes for FTP transfers, Web access, News reading, etc. On servers where sensitive corporate information is stored, DCE/Snare utilizes the DCE access control model to provide object level protection and auditing of each operation and each access. Unique to DCE/Snare is the ability to augment the authorization checks with location and time-based information. This means that you can implement a uniform access methodology across your NFS mounted file systems and FTP directories. Applications like OpenView and Netview can securely manage your network nodes with SNMP while access to individual OIDs in a MIB is governed by a standard DCE ACL. For the first time organizations will be able to implement a single, universal network identity for each user. All that is required is that the user perform a DCE login and obtain DCE credentials. The DCE/Snare will make these credentials available instantly to dozens of client/server applications across the corporate intranet. Since the DCE identity is universal, any data that is tunneled through DCE that carries this identity can be secured and authorized on any machine throughout the corporation.

But what of those machines that do not have DCE capabilities (yet)? How do they interact with machines that are completely secured by DCE? Ideally we would want to provide these machines a DCE security context that would be used whenever they attempted to contact a secure node inside the secure environment. This would put them on equal ground with their DCE counterparts. Through a companion product called DCE/Snare-Lite(TM), we do just that. The DCE/Snare-Lite enables a non-DCE machine to request DCE credentials from a DCE/Snare machine, using the DCE machine as its proxy login process. The initial communications between the two machines is secured using public key technology. The DCE security database acts as the certificate authority for the public keys that are distributed to the non-DCE machines. With this lightweight companion product, the DCE/Snare enables large corporations to rollout DCE in stages, across different platforms, without the risk of compromising the security of the organization and the integrity of the information stored within it.

IntelliSoft's DCE/Snare is a complete solution to the problem of securing individual nodes inside the corporate intranet. It brings the powerful features of firewall technology to each and every node in the network without forsaking the scalability and manageability of the environment. DCE/Snare, through its ASF, is completely extensible to support new TCP/IP-based protocols, so it can grow as the Internet "grows." This guarantees the viability and usefulness of a DCE security infrastructure for years to come.

RETURN TO TABLE OF CONTENTS