This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

April 13th, 2010 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

Security Working Group Meeting

Back to Security Main Page

Attendees

Agenda

  1. (05 min) Roll Call, Approve minutes 6 April 2010 & Accept Agenda
  2. (55 min) Security and Privacy Ontology Project

Minutes

1. Action Items

Reminder: Composite Security and Privacy Domain Analysis Model ballot is now open. Please vote!

2. Resolutions

Minutes of 6 April were approved. Motion to approve by Mike Davis, seconded by Suzanne Gonzales-Webb

3. Updates/Discussion

Security and Privacy Ontology Project

Brief update on the project:

  • Mike attended the SOA Ontology project call on Monday, April 12 and reported that Protégé v.4.0.2 has been selected for use (the most recent and stable version of Protégé)
  • Mike also reported on discussions taking place within the OASISXACML committee with respect to ontologies
    • The committee approved a work item to investigate ontologioes and a follow up call took place with Jericho Systems to discuss strategies and determine how Jericho would be involved. The management of Jericho is concerned about how this work might impact their products so this needs to be resolved.
  • The Security and Privacy Ontology project will be following the OASIS XACML committee activities as well as the SOA Ontology project as there are there opportunities for us to harmonize wit those efforts


The focus for today’s meeting (which extended into the CBCC WG hour) was a presentation on developing an ontology for Role-based Access Control using Protégé by Tony Weida. Prior to delving into the Protégé tool demonstration, Tony provided an overview of Description Logic (DL), OWL and the Protégé-OWL editor plug-in. (During the presentation, Tony used the alpha version of Protégé v.4.1.)

Some important concepts related to ontologies touched upon during the presesntation include:

  • Classes versus individuals
    • Classes: when you’re dealing with a kind-of-something (concepts) and when you want to allow further precision
    • Individuals: when you’re dealing with things that have an identity and can be counted (atoms), or you don’t need further precision.
  • Open world assumption: Anything may be true unless it is proven false. This is in contrast to Closed-world assumption (e.g., database) where anything that cannot be found is assumed to be false.
  • Primitive classes versus Fully Defined classes
    • Primitive: To be a member of a primitive class, an individual must either be directly asserted to be a member, or must be a member, by assertion or by inference, of a subclass. Primitive classes have only necessary conditions. Primitive classes are shown in Protégé with a simple circle icon
    • Fully Defined: Defined classes have one or more necessary and sufficient conditions. Defined classes are shown with an equivalence symbol in their icon.
  • Necessary and Sufficient Conditions (≡): Necessary and Sufficient refers to relationships between statements. The assertion that one statement is a necessary and sufficient condition of another means that the former statement is true if and only if the latter is true. The combination of necessary and sufficient conditions make a class a fully defined class.
  • Subsumption: Class-Superclass relationships. A class subsumed by another is called a subclass of the subsuming class. Each class includes its subclasses, but classes can have multiple parents.
  • Disjointness: Classes are not disjoint by default; partial overlap of classes is assumed. Disjointness must be made explicit.
  • No unique name assumption: different names may refer to the same entity, but OWL provides explicit constructs to express that two names denote distinct entities
  • Reasoner: There are a number of Protégé-OWL plug-in reasoners that can be used with Protégé 4.0.2 using a DIG (Description Logic Implementation Group) compliant interface. Pellet and FACT++ are two open-source reasoners that can be configured to run in Protégé. A Reasoner allows Protégé to compute subsumptive relationships between classes and detect inconsistencies between classes. OWL provides the necessary expressivity to write class expressions for a reasoner to infer the polyhierarchy: universal restriction (only), existential restriction (some), number restriction (min, max, exactly), boolean operators (or, and, not), etc.
  • OWL-Viz plugin: enables you to visualize class hierarchies in an OWL Ontology, allowing comparison of the asserted class hierarchy and the inferred class hierarchy. The inferred class hierarchy is generated once the asserted class hierarchy has been classified by a reasoner.

Next steps:

  • The Protégé tool can be used to support the goal of the Security and Privacy Ontology project. The purpose for the ontology is to support the ability to automate access control decisions. This is a different approach than is what is currently available since the types of rules governing access have to be hard coded into Access Control engines.
  • We can use the Composite Security & Privacy Information Model to create an ontology that can be used by an XACML engine to make access control decisions. So for example, if the relationships of the objects in the permissions catalog change, the policy engine can make revisions based on those changes without one having to go into the engine and re-write the rules.
  • In terms of next steps, we can start with two areas of the Information Model (IM). The first is RBAC, which has a vocabulary important in Access Control (AC), but is not enough to support Access Control. Once we've modeled RBAC we can proceed to the next important area of the IM that modifies Access Control - Patient Consent Directives.
    • Stated as a simple policy, e.g., “Dr. Bob can CREATE new lab orders”, or “Dr. Bob can READ Lab orders except if patient Jane says Dr. Bob cannot see her lab orders”. We could try to model those types of rules in our ontology.
    • The RBAC and Patient Consent Directives ontolgies can be integrated into a single policy representing the permission set that is modified by patient preferences. This could be quite useful even if it isn’t complete in terms of the entire permissions model and something that is of interest to both Privacy and Security domains.


Kudos to Tony Weida for an excellent presentation. We will continue these discussions in the following weeks.

Meeting was adjourned at 3:00 PM EDT.

No significant motions or decisions were made.