The Internet originally interconnected a small number of computers at universities and research labs. It was used to share resources and to send e-mail - an incidental application that over time grew into one of the major uses of the network. Everyone knew everyone else, and security was far from the priority that it is today. All this has now changed....

These days, security is a top priority for ISPs and consumers alike. Hundreds of millions of people are now connected to the Internet and items of tremendous value are at risk daily - from stocks and bonds to military and government secrets.

Security comes to mind as the topic for this month's CORBA Corner because every spring the Object Management Group hosts a workshop on Distributed Object Computing Security, or DOCSEC. This year's conference was also cosponsored by the National Security Agency (NSA) - which has been involved in every workshop since their inception - and by Concept 5 Technologies. Because so many vendors and serious security users get together to describe their experiences at this workshop, it provides an excellent opportunity to sum up the state of distributed object security. I'm starting this column with descriptions of a few standard distributed-security architectures to establish a base; then I'll summarize key points from the conference.

Security in Java and EJB
In Java, network security is commonly provided by the Secure Sockets Layer, which adds a secure network connection to the Java "sandbox." The SSL implementation - depending on the cipher suite - provides identification and authentication (primarily authenticating the server to the client), and may protect messages against interception (by encryption), modification (with a checksum) and replay (with a timestamp).

Chapter 15 of the Enterprise JavaBeans 1.1 specification defines a somewhat richer security architecture, albeit with a looser set of rules. Fundamentally, it places responsibility for security on the container (and therefore on the container provider), removing the burden from the application developer and allowing security policies to be set and changed at assembly or deployment time rather than development time. Security functionality includes individual privileges, group privileges and delegation, although the details are left to the container, which in addition defines the principle and its format. Because the EJB security model is defined in terms of a single container environment, it doesn't define a network protocol nor does it tell how to spread a security umbrella over containers from multiple vendors.

CORBAsecurity
CORBAsecurity defines a much richer security architecture. As with SSL, it starts with identification and authentication of the client, the user (without restricting the authentication mechanism, which might be a password, code card or a biocharacteristic such as thumbprint or retina scan) and the server to ensure that the client isn't talking to a "Trojan horse." It also places a checksum on the message to protect against modification, encrypts it to protect against interception and includes a timestamp to protect against replay.

Going further, CORBA refines the concept of delegation. Earlier we mentioned delegation without giving a definition. Delegation occurs when our client calls an object to perform some operation for us and that object, instead of performing all the work itself, delegates part of it to some other object that it invokes on our behalf. Nothing restricts delegation to a single level - multiple layers of delegation are common in object-oriented systems, whether local or distributed. When we program a client to invoke an object, we may not assume that the object will perform the entire operation itself. In fact, we may not even assume that the operation will execute on the same hardware that we dispatch our invocation to.

In its simplest form, delegation takes the form of impersonation - the intermediate object passes the caller's credentials down the chain. This object - and all other objects that receive them - is empowered (at least as far as security is concerned) to do anything that the client could do. Imagine passing this power to a server that makes transactions on your bank account or your retirement account. If you didn't have absolute trust in the first server object to do the right thing every time, you'd be very reluctant to make the first invocation. While this simple form of delegation is all that many environments provide, CORBAsecurity defines a number of refinements restricting, for example, which objects are authorized to use the credentials for delegation, how many levels deep delegation may proceed, which privileges are delegated or how long the credentials remain valid.

But wait, there's more. In a system with an established set of resources - including objects in a CORBA system or CPUs, printers, disks and files in other systems - you may want to control access to individual resources or to classes of resources, either by individual users or by groups of users. This is done by defining permissions in access control lists (ACLs), which are then enforced by the security infrastructure. CORBAsecurity includes ACL-based restrictions.

You may think that a perfect security system is one that can't possibly be breached, but it's not true. Security experts know that any security system can be breached - in an otherwise perfect system, by insider access - so the best security architectures and installations audit security-relevant actions. When there's an actual or suspected breach, security administrators can examine the audit records, hopefully identify what happened, fix the damage and possibly identify the perpetrator.

And finally, there's one service that falls under the security umbrella: nonrepudiation. This function relies on a trusted third party to permanently archive evidence of something important to a transaction on behalf of both parties - for example, that a source really did originate a message (which might be an order or something electronic of intrinsic value, such as a program or musical recording) or that a site really did receive a message or electronic payment. Nonrepudiation, therefore, plays a vital role in some B2B transactions.

State of the Market
The state of the market for CORBAsecurity implementations is very good. Four of the companies attending this year's DOCSEC had solutions. Let's look briefly at two of them now; the other two, from Adiron and Gradient, will come up in our presentation of the Workshop proceedings.

Concept 5
Workshop cosponsor Concept 5 furnishes the security implementation marketed as Orbix Security 3.0 by Iona and as TPBroker Security by Hitachi. This engine will appear on the market with other ORBs in the future. Implemented in an ORB-independent manner, it provides CORBAsecurity Level 2 functionality, including authorization and identification; access control, including both individual and group privileges and support for multiple domains; delegation in a number of forms; auditing; administration and (going beyond the CORBA specification here) support for single sign-on - a welcome feature, especially in large enterprises. Even though the Orbix product entered general availability just last March, six large enterprises are already progressing toward rollout, with implementation architecture studies well underway.

Tivoli Systems
IBM subsidiary Tivoli Systems, Inc., markets a CORBAsecurity implementation named Policy Director for CORBA. Also ORB-independent, it's available for both C++ and Java versions of Orbix and Visibroker (allowing them to interoperate securely), as well as for IBM's ORB. IBM's WebSphere, Enterprise Edition, incorporates security based on this implementation. With Release 3 in general availability since the first quarter of this year, Policy Director for CORBA has already been put into production at T. Rowe Price, a European telecommunications company and a large multinational bank.

The Workshop
Two days of tutorials (the first on CORBA, the next on CORBAsecurity) were followed by two days of papers and panels interspersed with lots of good discussion. Each of the final two days was divided into three topical sessions and a panel discussion. On the first day the three sessions covered Commercial Systems, Legacy System Integration and Government/Defense Systems, and the panel moderated a Security Users' Roundtable. On the second day sessions covered Standards, Policy Management and Performance Issues, and the panel moderated a Security Implementers' Roundtable.

OMG has posted electronic copies of the workshop slide presentations on the Web at www.omg.org/meetings/docsec/presentations.html. While I'll describe many of the presentations here, space restricts me to just a few sentences for each, so if this piques your interest, head for this Web page. You'll miss the speakers' comments, however, which are important since most slides aren't the entire story for the well-presented material at this workshop. And you'll miss the audience interaction too; since this was very much a workshop and not a conference, much of the value of this event came from the audience give-and-take. If you find yourself wishing you knew more, watch for notices for next year's event and attend in person!

Commercial Systems Session
Viktor Ohnjec, of Genesis Development Corporation, opened the Commercial Systems session with a presentation on gathering security requirements. He explained why security-sensitive applications should be designed with security in mind from the get-go - not grafted on at the last minute. This helps prevent blunders that may compromise security or cost more than necessary (or both).

Dr. Stuart Katzke, chief scientist for the Information Assurance Solutions Group of the U.S. National Security Agency (NSA), spoke about the NIST/NSA National Information Assurance Partnership (NIAP) program for information assurance. The Common Criteria (CC), an ISO standard, defines security functionality requirements. Companies may spend a lot of time and money not only building systems that comply with the CC, but also testing these systems and having them certified compliant. Until now, certification by a laboratory in one country hasn't been recognized by other countries, forcing the repetition of duplicate procedures in country after country. To save companies time, money and resources better devoted to developing new security functionality, and to make more certified products available, a number of countries have banded together to accredit each others' testing laboratories and to mutually recognize their evaluation results. Current participants are the United States, Canada, France, Germany, the United Kingdom and, just recently, Australia and New Zealand. For more information, surf to http://niap.nist.gov/cc-scheme/.

Integration of Legacy Systems Session
Speakers in this session were Sam Lumpkin of 2AB, Inc., Heather Hinton of Tivoli and Ulrich Lang of Technosec. Sam started with security requirements, but didn't repeat any of the points from the first talk. He pointed out, for example, that at a large enterprise you might be required to trust every employee at one level, contractors at a lesser level and outsiders not at all. That might sound okay, but when you ask for lists of employees and contractors, you may discover that the lists don't exist because Human Resources records may be out of date, or because lists of contractors may be so incomplete that they're nearly useless. When this happens, which it does often, even the best security installations can't give the protection that management counts on.

Heather discussed the effects of components and composition on security, showing that security isn't compositional and trust isn't transitive. Ulrich pointed out the complexity of the telecomms environment - multiple companies each providing multiple services with multiple components. Not only can an individual service consist of multiple technical parts, but in order to be successful it must also interact with billing and other business services to provide income for the company. One essential part of this multicompany technical and business environment was nonrepudiation, described earlier.

Government/Defense Session
GCHQ, the UK's analog to the USA's NSA, prototyped their security requirements using commercial CORBAsec implementations: ORBacus 3.1.3 from Object Oriented Concepts, Adiron's implementation of CORBAsecurity and Java 1.2.2. They discussed where their prototype succeeded, where it encountered difficulties yet still managed to operate and where it just couldn't manage. For details - and there were many - check the slides on OMG's Web site.

Users' Roundtable
Six security users participated in the roundtable at the end of the first day: Viktor Ohnjec of Genesis Development Corporation, a consulting company that designs object-oriented systems for many large enterprises; Sam Lumpkin of 2AB, Inc., another consulting company well known for their CORBA work; Ulrich Lang of Technosec, a small consultancy concentrating on CORBA security, particularly for telecomms applications; Jia-Ling Lin from Eidea Labs, a company with an object-based infrastructure and framework product; Alberto Avritzer from AT&T, who brought in his company's experience with large-scale secure developments; and someone from GCHQ who added CORBA knowledge, security knowledge and experience to the panel. This large and diverse group of security users provided a detailed and entertaining session. Moderators were Dr. Richard Soley of OMG and Jishnu Mukerji of HP.

Viktor Ohnjec, in his opening remarks, said that his company was frequently called in after a system went online and the security pieces didn't work. Typically, they found that security was designed piece by piece, probably after everything else was frozen. Designs and architectures that took security into account from the beginning were much more likely to succeed. Alberto Avritzer sketched the scale of AT&T's software environment and their security requirements. They run an interoperability laboratory and require vendors to demonstrate interoperability and compliance to standards when they purchase software. A representative from GCHQ said they were moving to EJB and application servers, but intended to keep using C++ (both legacy code and newly written apps) and therefore needed a standards-based environment.

Panelists and members of the audience discussed security modularity in terms of the OMG specifications and what's available in the industry. For modularity the standards use GSS-API interfaces to the components that provide basic security functionality. Unfortunately, the most popular over-the-wire security mechanism is SSL, which doesn't conform to either GSS-API's interfaces or its functionality profiles. All agreed that making an SSL-based security system interoperate with a GSS-API system is a challenge!

Richard Soley challenged the panelists and audience with the following question: "Is security hard because the tools make it hard, or because the problem is intrinsically hard?" He proposed that security was just plain difficult. David Chizmadia pointed out that CORBAsecurity interfaces for users weren't complex and that most of the complexity was for the implementers. The user interface set is small, and for people who are willing to use defaults, it's easy to use. The complexity for the implementer comes in making the application programmer interface small.

State of the Standards Session
Starting day two, Petra Hoepner of GMD Fokus described a telecomms middleware platform that takes a customer from online service subscription through provisioning and delivery of the service to online billing. It's based on OMG and TINA-C standards, and requires security throughout. Diagrams in the slide set show the various forms that security must take as you work through the stages of the interaction, so be sure to check the presentations Web site for details.

In a presentation that could have been a bit dry but instead kept everyone's interest, Polar Humenn involved the audience in working out the formal calculus of delegation, credential usage and other security functions. Polar, who is very active in security at OMG and is also chair of OMG's Security Revision Task Force, will use the results to guide the evolution of CORBAsecurity.

Security Policy Management Session
In the next session Polar presented a new model for access control in Level 2 CORBAsecurity, and Alex Kotopoulis of Segue Software discussed enforcement of business rules using a tool based on OMG's licensing CORBAservice.

Performance Issues Session
In the final session before the Implementers' Roundtable, three investigators presented measurements of security's impact on performance. David Shambroom of GTE Laboratories, who began his project before implementations of CORBAsecurity were widely available, implemented his own CORBAsecurity using SSL and interceptors, and found the expected linear dependence on the number of operations and data size. The tables in his slide set showed the dependence on machine architecture and encryption algorithm. Patrick Dunne, a consultant working for GCHQ, presented measurements on the commercially available Adiron security implementation. Adding credentials to IIOP didn't slow it down, but moving to SLIIOP did. Finally, Tammy Blaser of NASA presented the most detailed set of measurements. NASA is building a jet engine simulation package for use by suppliers. It's written in C++ and distributed securely using CORBA. Data size dependence on security shows a peak at small payloads from initialization overhead - linear dependence beyond this peak reveals the encryption load. The slides on OMG's Web site show Tammy's data in detail.

Implementers' Roundtable
Not all of the Implementers' Roundtable participants came from companies that produce and market CORBAsecurity products. Ron Monzillo, lead on J2EE security, contributed insights on interworking between Java and CORBA security, especially important now with the close ties between the CORBA Component Model and Enterprise JavaBeans. Gregg Tally of Network Associates represented their firewall product, which supports IIOP, although it doesn't use OMG's firewall specification. Fred Dushin spoke for Hitachi America, which resells Concept 5's product on their platforms. David Chang of IBM represented their CORBA product as a total solution, which includes security - as Level 2 CORBAsecurity - where it needs to. Three vendors spoke about their own implementations: Polar Humenn of Adiron, Ryan Eberhardt of Gradient and Don Flinn of Concept 5.

The audience asked questions regarding access control, nonrepudiation, auditing, delegation and other capabilities besides the wire protocol and transport aspects that seemed to dominate the two days of presentations and discussion. Speakers from various companies, including Concept 5, Adiron and Sun, pointed out that they had rich security functionality and hadn't neglected these aspects.

Don Flinn pointed out one very important reason to include auditing capability: certain large computer users, especially hospitals, can't use strict access control because if it causes a delay, or if lack of a password prevents access, patients could die. Instead, they audit every action on the system. In response to a question on security in Microsoft's products, Polar pointed out that their security primarily used Kerberos and that interoperability with their certificates and authentication structure should be possible. As the roundtable closed, Richard Soley followed up a question about security interoperability by asking who would participate in a security interoperability showcase at next year's DOCSEC workshop. Everyone on the dais said they would. Have we mentioned that we expect next year's workshop to be really interesting?