Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
R3 in Action
Once upon a time my colleagues (Scott Hissam and Robert Seacord) and I were helping a Defense Department program migrate a large, custom legacy system to an open, COTS-based system. The program had made an early commitment to a Web-based solution, and was considering whether to repackage legacy services as CORBA-based services and provide thin-client access to these services via Java applets running in Web browsers. Even three years ago this ensemble was known to be feasible (Web browser and server, CORBA servers, Java applets). The real question, however, was whether this ensemble could, in a practical way, be made to work securely.
To support identification, authentication, authorization, and confidentiality, the ensemble illustrated in Figure 2 was proposed. (You can guess the age of the example from the component version numbers—they were current releases at the time.) The Web server would identify and authenticate (I&A) users accessing the system from their Web browsers. An authenticated user would receive a CORBA interoperable object reference (IOR) from the Web server. This CORBA object would contain the user’s permissions on the system for a particular session. Each operation performed by the user would be tagged with this session IOR, allowing back-end services to check a user’s authorization to invoke a service. Using CORBA interceptors would allow us to do this session-tagging transparently to applet developers. Last, all interactions between the requesting applet and back-end services would be transmitted using the CORBA IIOP protocol over a secure socket layer (SSL) connection, thus guaranteeing confidentiality.
){kind=link}
Figure 2: A Secure Web Ensemble
Recall that model problems are toys with design context and evaluation criteria. In this ensemble the design context included all of the concrete component versions in the proposed ensemble. The evaluation criteria were simple. First, it had to work. That is, the sequence of steps numbered 1-5 should transpire once when an applet is downloaded to the browser and steps 6-8 whenever the applet requested a service. Second, we wanted the security services for authorization and confidentiality (all of the interactions among the shaded components) to use the same digital certificate information used by Netscape to do its identification and authentication in steps 1-2. This was important because we did not want to have duplicate security infrastructures, and we did not want to add any more client-side administrative burdens beyond that which was already required to use a browser with digital certificates.
The toy we constructed was as simple as we could make it, but despite our best efforts we still had to do a significant amount of component configuration. For example, setting up the certificate-management infrastructure required that we develop a security policy for our toy that addressed matters such as who is allowed to issue certificates and whose certificates are trusted. As with all good toys, the amount of application-level code was minimal—the security manager and storage manager involved only a few dozen lines of code, and the applet and server-side JavaScript needed to generate the applet were also quite small. As small as it was, the toy was sufficient to test against the evaluation criteria.
What was the result? Problems arose when we tried to get the applet to establish an SSL connection for secure IIOP between the applet and storage manager. VisiBroker required the applet to supply a private key to configure the client side of the SSL connection. Although VisiBroker would accept the private key portion of the public/private key found in the user’s digital certificate—the same certificate used to authenticate the user in steps 1 and 2 of Figure 2—there was no way to programmatically retrieve this key from the Netscape browser. We suspected that this was because Netscape feared that if they did so they would be in violation of export control laws concerning key management technology. Regardless of the reason, the end result was that the ensemble provided all of the required security attributes except confidentiality.
This did not mean, however, that we were prepared to abandon the secure Web ensemble. We had a fallback position of course (we always do), based on simple use of Netscape’s server-side JavaScript in lieu of applets (Java servlets were not yet available). But as a rule we try wherever possible to avoid relying on vendor- or component-specific languages, as these are liable to change causing later maintenance headaches (to say nothing of vendor lock). The secure Web ensemble was based on de facto industry standards—HTTP, Java, CORBA, X.509—and we thought there were better long-term prospects for this design approach even if there were near-term risks. After some reflection, we hit upon two possible repair strategies. One strategy involved trying to discover how Netscape did its key management on the browser side so that we could impose our own application-programming interface to extract the private key. Another repair strategy was to achieve confidentiality through a hardware encryption with a network interface card.
Both of these repair options became design contingencies. Both of these contingencies required further investigation including, ultimately, the development of model problems to validate their feasibility. Readers interested in discovering the results of these investigations might wish to read Into the Black Box: A Case Study in Obtaining Visibility into Commercial Software and COTS in the Real World: A Case Study in Risk Discovery and Repair. But the real point of the illustration is not to provide the specific technical details of the model problems (most of which have been suppressed), but rather to reinforce the message that design risk reduction in COTS-based systems involves very detailed, implementation-level investigations. Any area of uncertainty in how a component or ensemble works to satisfy a key need is an area of risk that must be resolved as quickly as possible.
In this illustration we were able to expose the design risk and find a workaround based on our discovery about how Netscape manages its public and private keys. As I mentioned already, we had a fallback in case the ensemble would fail. Sometimes, however, a fallback is not available, especially if, as is frequently the case, system requirements were influenced by the perceived capabilities of an ensemble. What happens if these perceived capabilities turn out to fall short of the mark? This brings us to the topic of iterative development, and "wheels within wheels."