Mini-Tutorial on OMG

Craig Thompson

Object Services and Consulting

Context

Relevant Standards Development Organizations

OMG - hope to cover

OMG at a Glance

Organization

Architecture

Typical Mode of Operation

OMG List of Documents

Specifications - Adopted and Planned

Reference: http://www.omg.org/library/schedule/Technology_Adoption.htm

ORB specifications

OMG CORBAservices

CORBAfacilities PTF

OMG Internet SIG

Simulation SIG

Business Objects DTF

Electronic Commerce DTF

Finance

OA&D DTF

Manufacturing

Telecom DTF

CORBAmed

Hot Topics at current OMG meetings

OMG Space, Time, Uncertainty (Tenney asked for status)

OMG Security (Fabian asked for status)

Conclusion

For Further Information

Security Requirements, Henry Rothkopf, National Imaging and Mapping Agency (NIMA)

(from Minutes of Internet SIG Meeting #10)

Henry described deficiencies of today's security systems and provided handouts on a large (preliminary) study done with a lot of MITRE and other inputs. He pointed out that the DoD realizes that most security issues are generic to industry as well as Government and DoD needs such schemes to be in widespread use, and then wants to be able to add-on GOTS (e.g., Government off the shelf) requirements. Henry advocates coming up with a single threat model for commercial and Government use. There will always be some GOTS requirements but threats for both are similar.
He requested inputs from OMG on the draft report (handout). He stated that today, in the DoD we have some working "system high" systems (enforces need to know) and very few, very expensive multi-level systems, expensive because they require assurance on the development side. But in the next generation, we need more modular security that supports multiple communicating domains with generic security available at several levels in protocol stacks. At a course grain, this includes wrapping whole collection of items with one label like "imaging". At a finer grain level there might be multiple CORBAs talking to each other using access privileges. He indicated that scalability requires that we must communicate policy across domain boundaries. Also we need to be able to change security policies in running systems. We don't know how many such systems we are talking to at any given time. Each domain is mutually suspicious but we must communicate until we are done. This is a big step beyond today's firewalls. It requires an inter-domain import/export policy; a label-based scheme appears doable but depends on additional management that we don't do today. It is also a step away from C1, B2, etc. levels of security aiming at a richer scheme for insuring safeguards in federated systems with mixed security levels.
Q from Craig: This is very different from firewall technology - much more robust (and complex). How will the transition take place. Have firewall vendors been contacted? Response from Pat Mallet: as industry sees the similarities, migration should happen. Response from Neil Wagoner: First step is to develop a combined threat model. Second step is to determine what can be done in the CORBA environment and what cannot.
Q from Craig: What about Virtual Private Networks? How do they relate? Response: VPNs only address some security levels - Virtual Private Networks are lower level and do not transfer information across boundaries.

Firewall RFP, John Sebes, Trusted Information Systems (TIS)

(from Minutes of Internet SIG Meeting #10)

See briefing and draft ORBOS RFP security/97-02-07: CORBA/Firewall Security Request for Proposals, draft
What are issues relative to Internet? Why is the RFP needed?

Firewalls requirements

Feels that this is not a final answer in and of itself. SSL provides edge to edge security - another part of the answer. Secure IIOP allows third party security - based on RSA cryptography.
Java applet communicating from outside the firewall (single firewall) - requirement included in draft RFP?

Implementing a firewall that works with IIOP is easier than other technologies (e.g., DCE)

Security Architectures for Distributed Enterprise, Bill Johnston, Lawrence Labs

(from DOE 2000 Workshop in conjunction with DARPA IC&V Workshop)

not connected to OMG, just interesting

Interesting talk on security. The use-condition model is more general than security and seems to be useful for any abstraction. That seems to be the value-added. Johnston should come to OMG Security meetings.
Collaboratories physically separate users from machines they use. How can users impose use conditions and security on the machines when they are remote? Slide shows first-generation solutions to future solutions: Physical Protection (safes, guards, and fences) to Blanket Info Security (ACLs, firewalls, authentication, intrusion detection) to Specific Application Security (public key, EBT, EDI, EFT, identity certificates, current Web) to Enterprise Security (public key infrastructure, enterprise functions, electronic commerce, authorization certification). Requirements in financial services and scientific communities are similar (comparisons: electronic notary, authenticating log books). Johnston is working on use-condition centered models. Attribute certificates - do you have your X training? Yes, pull out card indicated class X from authority. Need distributed certificate authority. Responsibility for actions is traced back to individual through unbroken chain of certificates. In their model agents and brokers create contracts. Having to pay for a resources is another attribute. Use-condition is a short-hand for certificates. Access Control Lists (ACL) are a special case. Johnson reviewed public key. Names are handles for public-key. Certificates are secure documents that participate in the security infrastructure. Another element needed is signing mechanisms. Put it all together and you get a Use-Condition Model. Individual (Identity Authority, many attribute authorities (drivers license)) plus resource authorities tied together provide capability. Add to this access control (who grants, where is use-condition, and resource). Finally, described overall architecture. One part is smart shell, another is mini-SQL for looking up security attributes on the web. Using JYLU and IETF GSS. None of this can be exported though they use standards and all software is coming from Australia or Finland.