You are here: The Open Group > The Open Group Conference, Austin 2011 > Proceedings

Security Forum

Objective of Meeting

The objective of the Security Forum meetings was to progress all the items listed in the Security-Jericho Forums agenda for this meeting:

Monday July 18:

  • Plenary and tracks addressing Strategic View of Secure Computing in 2030 – see more details in the Summary below.

Tuesday July 19:

  • Plenary and tracks addressing Security Management Challenges and Transformational Opportunities – see more details in the Summary below.

Wednesday July 20 (Public Sessions):

  • Building a Cloud Computing Roadmap View to your Enterprise Planning
  • Cloud & Security: Architectural Decisions Rodeo

Wednesday July 20 (Members' Meetings):

  • Joint meeting with the Trusted Technology Forum
  • Dependency Modeling: project status review, update, and development
  • The Open Group brand, logo, web
  • Response to NSTIC Notice of Inquire
  • Security Management: next steps on ISM3
  • Automated Compliance Expert Markup Language (ACEML) – the way forward

Thursday July 21 (Members' Meetings):

  • Authorization Roles Mapped over RBAC (ARMOR)
  • Secure Mobile Architecture (SMA): joint RT&ES-Security Forum development workshop


Monday July 18: Plenary addressing Strategic View of Secure Computing in 2030

The speakers and presentations from the Plenary can be accessed here.

Tuesday July 19: Plenary and Tracks addressing Security Management Challenges and Transformational Opportunities

The speakers and presentations from the Plenary and following security tracks can be accessed here.

Wednesday July 20 (Public Sessions): Building a Cloud Computing Roadmap View to your Enterprise Planning

The speakers and presentations from this track can be accessed here.

Wednesday July 20 (Members' Meetings): Security and Jericho Forum

Joint Meeting with the Trusted Technology Forum

The meeting session focused on developing the O-TTF marketing messages, and on the TTF members' desire to submit comments to the drafts of ISO/IEC 27036 Parts 1, 2, and 3. The closing date for comments is September 20. We will clarify whether we should submit these comments to JTC1 SC 27 WG4 through The Open Group ISO PAS Submitter status via Andrew Josey, or via The Open Group Category C Liaison status to JTC1 SC 27 via Ian Dobson.

Dependency Modeling: Project Status Review, Update, and Development

Unfortunately due to indisposition of the project leader for this session, it had to be cancelled. New arrangements will be made to hold this members' review session in the next month via Conference Call or Webex.

The Open Group Brand, Logo, Web

Jim Hietala (VP, Security Programs) briefly explained the background to launching The Open Group new brand, logo, and web site, noting that most Forums have already held branding workshops. The guide to using this new brand will be published soon.

Response to NSTIC Notice of Inquire

Members present and via dial-in to the meeting reviewed The Open Group proposed response to the NSTIC NoI, and added additional responses in specific areas. Jim Hietala (VP, Security Programs) undertook to edit these additions into the document and submit it by the July 22 closing date.

The Jericho Forum leaders, having reviewed The Open Group response, decided to also propose a distinctly "Jericho" response based on the work that the Jericho Forum members did leading up to, during, and after publication of the Jericho Forum Identity Commandments, and which augments, not contradicts, The Open Group response. The members in the Austin meeting reviewed and commented on it in a conference call into the meeting, prior to the Jericho Forum separately submitting their response to the NSTIC NoI.

Security Management: Next Steps on ISM3

ISM3 project leader Vicente Aceituno (ISM3 Consortium) presented an overview of the next steps he recommends following publication of the O-ISM3 standard. These steps covered:

  • Developing a White Paper on "Using O-ISM3 Effectively with SABSA". This requires help from a SABSA expert to do mapping. An action was accepted to contact the relevant TOGAF-SABSA project members to request help from a SABSA expert on drafting this White Paper.
  • Maturity models: developed using O-ISM3 standard. Actions were accepted to arrange meetings with possible industry groups in Spain and with BITS and/or CUISP (credit union security professionals) to socialize O-ISM3 as a methodology for use by respective industries, and test the idea of working on maturity levels appropriate to them, collaborating with them to develop these.
  • Certification programs: O-ISM3 maturity models; ISM3-certified professional. An action was accepted to circulate a strawman business justification for a certification program for O-ISM3.
  • Proposed White Paper: Enhancing Value of ISO 27001/2 using O-ISM3. An action was accepted to draft a White Paper on "Using O-ISM3 with ISO 27001/27002".
Automated Compliance Expert Markup Language (ACEML) – The Way Forward

ACEML project leader Shawn Mullen (IBM) presented an overview on how the O-ACEML standard supports translating business vision and drivers into business capabilities, its general process flow, and the key features that the ACE mark-up language provides.

Future Developments

Moving forward, options for future developments include:

  • DMTF OVF: The Distributed Management Task Force (DMTF) Open Virtualization Format (OVF) is the current state-of-the-art technology to package and distribute software to be run in virtual machines. The OVF standard specification is based on the open content model, which makes the ACEML –OVF integration easier. This is a good fit but we should focus on broader adoption in primary use-cases before pursuing it, so DMTF integration will not be pursued at present.
  • TNC (Trusted Network Connect) Integration: Integration with the TNC Integrity Measurement Collector is an apparent need – providing a good fix – but we should focus on broader adoption in primary use-cases before pursuing this, so it is assigned low priority at present.
  • SCAP Integration: The SCAP model relies on a system being correctly identified via CPE (Common Platform Enumeration) or a unique identifier number.  These references are then used to look up the CCE (Common Configuration Enumeration), which is then used to find the associated Extensible Configuration Checklist Description Format (XCCDF) configuration rules. The XCCDF is then applied to the system end point to set the configuration or query the configuration. Integration involved and will require co-operation and commitment from NIST and Mitre. Significant issues are that SCAP is very focused to US Government requirements, and the SCAP model involves a significant level of skill and learning curve to implement, so not easily accommodated by smaller enterprises. Propose opening a dialog with NIST and the SCAP developer community, starting sooner rather than later. We could also start work on defining a DoD STIG in ACEML. This should be assigned medium priority.
  • Payment Card Industry Data Security Standard (PCI DSS): This has the largest customer set of the options reviewed here, so therefore represents the biggest opportunity for benefit and cost savings. We need to establish a credible, collaborative relationship with the PCI community. The best way to do this is to commit to defining PCI-DSS in ACEML.

Summarizing, actions moving forward in the next three months are:

  • Continue with PR – via a podcast, and contacts with analysts
  • Meet with PCI 
  • Develop ACEML definitions for PCI-DSS and DoD STIG
  • Engage with NIST and Mitre on SCAP

Thursday July 21 (Members' Meetings): Security and Jericho Forum

Authorization Roles Mapped over RBAC (ARMOR)

RBAC is supported by major Operating Systems such as AIX, HP-UX, Solaris, and SE-Linux, but each OS chose different role and authorization names. To resolve this shared problem the ARMOR project members are developing a standard mapping between different Role-Based Access Control naming spaces. This session was run as a live ARMOR development conference call with ARMOR project members IBM, HP, Oracle, and SE-Linux.

Project leader Shawn Mullen (IBM) preceded the ARMOR development call with a summary from an earlier UNIX Business Strategy meeting in the Austin conference, in which six focus areas were identified:

  1. Scalability: Improve Single UNIX to improve scalability. Also notify long-running programs that configurations have changed; and address manifest constraints; e.g., call sysconf to learn that system variables have increased or decreased. Address APIs that can get to LDAP more efficiently via dynamic reconfiguration.
  2. RBAC: ARMOR will provide the solution here. RBAC is a “security” topic so sits comfortably in the Security Forum for the present development work, but at the right time it needs to be presented to the UNIX standards board to confirm that ARMOR will become part of the UNIX standard.
  3. Real-time Extensions: Basic real-time behaviors, not actually real-time.
  4. Virtualization: Shawn Mullen and Cliss need to develop a description citing examples for what this proposal will involve.
  5. Appliances/Optimized Solutions:
    • API so SAP can install by creating a VM, storage/filesystem, etc.
    • Standard on establishing a standard way to install/create an application on a virtual system, a hypervisor.
    • Genesis: multi-component aspects need to define the domain set of services. This provides for how an appliance can establish itself or be able to lay down VM and install and become up and running.
    • Assignment: Need to establish common service not assigned to anyone specifically.
    • Linux affinity

Shawn then gave a brief overview presentation on the problem space being addressed by the ARMOR project, and the two areas (Common Roles, Common APIs) being addressed, before moving into the development team’s regular weekly development conference call with the team members.

Secure Mobile Architecture (SMA): Joint RT&ES-Security Forum Development Workshop

The SMA is a joint RT&ES-Security Forum development project. Project leader Steven Venema (Boeing) set up a Webex in the Austin meeting to facilitate online participation by leading member-contributors. The current project plan is:

  • To use the existing draft SMA document to create an SMA Snapshot, which we plan to deliver in the August-September timeframe.
  • To develop an outline draft for an SMA Interfaces and Protocols specification, which we will develop over the next 3-6 months according to the availability and progress of external dependencies on the Trusted Computing Group, the IETF, and the Internet Security Alliance developing the necessary standards defining essential components to complete our SMA as an implementable Open Group standard.
  • To then update the SMA Snapshot by integrating the SMA Interfaces and Protocols specification into the architecture framework that's presented in the SMA Snapshot, and thereby supersede the SMA Snapshot by delivering a complete "SMA standard".

Members present conducted this session as a development workshop – reviewing the latest draft in the light of a proposed revised structure which was aimed at making the flow of the SMA Snapshot more readily assimilated. Actions going forward were agreed as mapping the existing draft content into this revised structure and reviewing the resulting draft. Assuming project members achieve agreement on this draft (target three weeks following this Austin conference), we will submit it to The Open Group Forum Review to approve its publication as our SMA Snapshot – aiming for publication by end September.


All objectives in the agenda were achieved except for the Dependency Modeling project status review and development, which was cancelled due to indisposition of the project leader for this session. New arrangements will be made to hold this members' review session in the month following the Austin Conference, via a Conference Call or Webex.

Next Steps

Actions were assigned as indicated in the Summary report above.  A more detailed assignment of actions is available to members from the Security Forum members-only web page.


See above.

   |   Legal Notices & Terms of Use   |   Privacy Statement   |   Top of Page   Return to Top of Page