Public Meetings
The speakers and presentations from the following public sessions are
detailed here.
Monday October 20:
- Plenary: Secure Architectures
- Stream C1: Security Management
- Stream C2: Managing Risk in the Infrastructure
Tuesday October 21:
- Track C: Secure Architectures (Stream C3 and C4)
Introduction
At the start of the Security Forum members' meeting,
members present introduced themselves, then reviewed and approved the agenda.
The Security Program VP presented a brief summary of the results in
the Members
Councils lunch on the Tuesday of the conference. Then in the Security Forum
meeting he presented a more complete review of the survey
results. The actual survey questions
and responses are available at: www.surveymonkey.com/MySurvey_Responses.aspx?sm=%2bn23Z13cVoiRg%2bOkZMUm7KhahgWqKWNmFTaa7NmeUqg%3d.
Comments included:
- It would be valuable for members to have a map showing which groups worldwide are working on what standards.
- We have TOGAF & SIB for architecture; should we think in
terms of creating anything similar for security?
- We should review the visibility of security issues in TOGAF, to check our
Security in TOGAF White Paper (W055) has been included in TOGAF v9.
We should also check whether we need to update our Security in TOGAF
White Paper to reflect how information security has moved on since 2004
when we published it.
Next Steps: We will collate and categorize all the SurveyMonkey
results so as to draw out the key outcomes. The Security Program
sub-committee will then review these results, conclude agreement on it,
and agree an action plan which modifies our 2009 Security Strategy plan.
The final Report and modified 2009 Action Plan will then be provided to
members.
The Security Program in The Open Group covers member activities in
the Security Forum, Identity Management Forum, Jericho Forum , and
Real-Time & Embedded Systems Forum. The Security
Program Roadmap lists all the current security activities and
deliverables. Specific highlights in our plans for 2009 include the
following three items:
Security Practitioners Conferences
The first Security Practitioners Conference (SPC) will be in The Open
Group San Diego conference, February 2-6, 2009 (refer to www.opengroup.org/sandiego2009).
The SPC page outlines the plans for SPC plenary sessions on Monday
& Tuesday mornings, with focus sessions on Monday afternoon on
"Identity in the Cloud" and on Tuesday afternoon on "Secure
Services in the Cloud". Then on the Wednesday is a separate one-day
conference on "Cloud Computing". So by the end of the
Wednesday, attendees to this conference should have had the opportunity
to hear and ask all the questions they have on Identity, Access Control,
and Secure Services, in the cloud. We are starting planning of the San
Diego SPC now, and look forward to help from members in finding the best
speakers and building case studies and business scenarios to use in
asking hard questions in the focus sessions. We will be looking at least
three months ahead in our planning cycle for each SPC through 2009:
- SPC#2 in London UK (April 27-May 1 2009)
- SPC#3 in Toronto, Canada (July 20-24 2009)
- SPC#4 in Hong Kong (October 20-23 2009)
Identity & Access Management
Identity and authentication remain top hot topics, and Identity
& Access Management (IAM) have already been put high on our
agenda for our first SPC in San Diego, February 2-3, 2009. Already we are
gathering case studies to build realistic scenarios which we will use in
examining the real challenges and requirements for IAM in the
cloud.
Jericho Forum working closer with Security Forum
The "lozenge" diagram illustrates the relative
positioning of the Jericho Forum with the Security & Identity
Management Forums. The Jericho Forum is nearing completed delivery of
its initial vision and mission as set out when it started in 2004, and
is planning a major PR announcement on this for San Diego, at which time
it also plans to announce its extended vision and mission, to take its secure
collaboration oriented architecture (COA) framework into the cloud – by
identifying the challenges and calling on solutions providers to respond
with interoperable (i.e., standards-based) products and solutions that
will make cloud computing secure for the enterprise.
ITSC Stream for Security Specialists
The Open Group's ITSC (IT Specialist Certification) program team is
led by James de Raeve (VP Certification, The Open Group). The ITSC home
page (www.opengroup.org/itsc)
explains the distinguishing features which make this ITSC scheme special
as an experience and skills-based certification which promotes career
development and proven recognition in the IT industry. Among the
existing ITSC participating members, security is a career strength, so
adding a Security Specialist stream would facilitate adoption of
information security in like organizations as a formal career
development path at three levels: certified, master, distinguished.
In our meeting in Glasgow (April 2008), the ITSC program team put
forward an outline proposal to add a Security Specialist stream to the
now-established ITSC program. The outcome from that Glasgow meeting was
that there is merit in considering it further, so the ITSC team took
away the feedback from that meeting and presented a modified proposal.
This proposal has been further revised by the ITSC team.
In our Chicago meeting (July 2008), Security Forum members provided
feedback on specific aspects of the ITSC Security Specialist proposal.
The ITSC team took this feedback away, and members of the Security Forum
undertook to review the revised ITSC Security Specialist proposal within
their organization to check if it is likely to be adopted as
representing worthwhile added value to their organizations as a career
path benefit, a team-building benefit, and a recruitment benefit, and to
recommend improvements based on their experience as expert security
practitioners.
In this Munich meeting, we clarified that the objective of
inviting Security Forum involvement in this project was primarily to
leverage the expertise of the Security Forum members, not to seek buy-in
on adopting the resulting ITSC Security Specialist program. The draft
ITSC Security Stream Requirements v0.4 was reviewed in detail,
addressing all the feedback received to date from the Security Forum and
also taking in improvement points arising from rigorous review by those
participating in the meeting. This resulted in a mark-up draft ITSC
Security Stream v0.5 showing
all the updates to the table of Security Skills, plus responses to the
Security Forum feedback both in the Chicago meeting and in follow-up
emails. The new v0.5 will be made available to the ITSC team and to the
Security Forum members, for review and further comments. Specific
actions arising:
- Add separate forensics criterion to the set of Security Skills (ITSC
team, by November 7)
- Consider and update the revised "general" definition (All, by
November 6)
- Ethics ... provide examples of ethics criteria from other
established certification schemes (e.g., CISSP, CISO) for
development of an ethics code of conduct, etc. (All, by end
October;
James de Raeve to then draft a proposal by November 6)
- Consider if Security Skill #1 should be mandatory at a higher
level (All, by November 6)
- After separate forensics Security Skill has been added, ask our
security specialists to:
- Sanity-check the complete list of Security Skills
- Advise what criteria they personally would meet, at which
levels
- Draft a recommended consistent set of questions (Bas, by end October, and James de Raeve to include in the October
6 draft)
SOA and Security
The Security Forum members joined three presentations in the Wednesday
SOA public stream which they selected as directly addressing Identity
Management & Access Control issues in SOA environments, to inform
their contributions to the SOA & Security project.
Presentation 1: Claims-Based Access Control
Andre Koot, Security Manager, Univé, Netherlands
Concept of multiple processes with specific owners and segregation of
duties such that each person in the hierarchy has assigned roles but
also covers for colleagues on an organized basis when other colleagues
are absent, because the process has to have continuity. In large
organizations, this can involve a complex management challenge. Not helped
because of cost of role-management, and understandings of "context"
– RBAC has no such concept. Federation, the Internet (no managed
identities), and SOA environments add more challenges. Solution might be
"claims", where an identity provider provides acceptable
validity of a person's identity and selected attributes; e.g., citizenship
in a passport, driving entitlements in a driving license. These
attributes allow for identity claims. We usually connect such identities
to roles. We can also connect the claimed identity/role to a profile.
RBAC will not work in SOA environments.
Presentation 2: A Service-Oriented Approach to User
Provisioning – Unexpected Architectural Challenges
Stuart Boardman, Director of Consulting, CGI, Netherlands
Today's business processes don't recognize perimeter divisions between
an enterprise and its customers/partners/suppliers, etc. Web2.0 is
accelerating this trend. Provisioning started by defining user IDs/passwords,
then roles, moving down to location and sub-function. So provisioning
expanded, and the identity concept likewise expanded to include
additional attributes and accreditations, and build profiles of the
person attached to a label which is your name. A model developed by the
TeleManagement Forum provides a rich model for identifying users, but
also for identifying individuals and for embracing roles. These
components build up a profile of the user as key business information,
such that we can still separate "inside" from
"outside", relevant business information, and how we might use
this profile to drive provisioning fro that individual. Conclusions are that if you can separate identity from provisioning, then you can make
the challenges more manageable. Of course we have a legacy problem to
handle in the real world, so we must keep this in mind.
Discussion raised the issue that this is an architectural challenge –
what organizational structure work is proposed to address this? Any
structural approach must be top-down, not bottom-up. An article
proposing RBAC2.0 helps to highlight the challenges in SOA. Claims work
OK when we have no substantiation (like we can accept payment as
sufficient to proceed) but the claim has to grow into a substantiated
model where a person can move from an untrusted claimed identity into a
trusted one, just as in real life. In Web 2.0 we have to authenticate
in order to give permissions, so because roles do not work in Web2.0 we
need some other solution to match access permissions to services
available, including to satisfy audit/compliance
requirements.
Presentation 3: Case Study: Identity Management
Interoperability in European Union
Arnold
van Overeem, Global Architect, Capgemini, Netherlands
Arnold introduced the relevant statistics on the EU administration, and how the
member states are diverse in their IT deployments in their Public
Administration systems, and their legacy and information systems, and
use of standards which facilitate interoperability. This leads to a lot
of manual manipulation of information. The EU Interoperability Framework
aims to address this problem, in several aspects. One area is in
electronic identities and authentication that will enable businesses,
citizens, and government employees to share common
identity/authentication schemes. The STORK eID project started in 2008.
There are two identity approaches: one (blue) where the government owns
the citizen's identity; the other green where the individual owns their
identity. How do we reconcile these different approaches?
Procedural approaches are that blue and green citizens have dual eIDs
(e.g., dual passports).
Progress FAIR Project
The FAIR (Factor Analysis of Information Risk) project page is here.
It provides access to all the development drafts, presentations, and
other materials related to this project.
Company Review of our Risk Taxonomy Technical Standard closed on July
29. There have been several valuable recommendations for improvements,
which have now been resolved in the final version, which completes its
sanity-check before being presented to The Open Group Governing Board
for approval to publish.
Security Forum review of our Risk Assessment Methodologies (RAM)
Guide closed on September 29. The comments received during this review have
now all been resolved, and the final draft is almost ready for final
editing and then a sanity-check, leading to approval to publish. The aim
of this RAM Guide is to identify the key characteristics that any
competent risk assessment methodology should include, and so enable an
objective evaluation of the value of any selected methodology.
Development of our Implementation Cookbook for FAIR began in September,
and an outline draft was presented for review in the meeting. The
discussion was led by project leader Alex Hutton, via conference call.
The approach is to demonstrate the applicability and usefulness of FAIR
in conjunction with at least one other risk assessment methodology. The
selected one was COSO. Others will then be able to use
the Cookbook by example, to create their own application paper to apply
FAIR to other frameworks; e.g., ITIL, 27001, CoBIT, OCTAVE.
We have licensing permission to use pages 49-54 of the COSO ERM, and
will check if we need to license more as the development of this
Cookbook progresses.
An additional proposed deliverable arises from Alex
working with a group on mapping pieces of FAIR to the ISO 27001 standard. They have a spreadsheet that maps specific sections and
highlights issues and comparisons. The outcome looks like it will
establish proof-of-concept of FAIR. This could be developed into a
further Cookbook deliverable which will help establish FAIR's high-value
credentials in the marketplace.
From the previous meeting (Chicago, July 2008), we established
interest in updating the NAC Enterprise Security Architecture document (available at
www.opengroup.org/bookstore/catalog/h071.htm) with a lead editor who was closely involved
in writing the original ESA
document, and a team of member contributors. The ESA document is a
substantial work. It includes coverage on Governance which reproduces
material licensed from the British Standards Institute's BS17799; this
license requires quarterly submission of number of downloads of the ESA
document, and payment of a license fee to BSI for each download. A
set of proposed revisions has been submitted, but the project leader's
availability has been delayed. We anticipate work will commence in
December 2008.
IBM have submitted a Charter outlining this work, and propose to
submit a specification under The Open Group's fasttrack review/approval
procedure. The automated
compliance expert (ACE) will create templates which will provide a
knowledge base in a format which can be consumed by compliance tools. These
tools will then be able to be populated so as achieve a high degree of
automated compliance configuration and monitoring in any given system.
The result will be to assure full compliance to a required configuration
and policy, with much reduced work to achieve and maintain it, so making
vendors' compliance tools much more efficient, and significantly
reducing end-users' cost of compliance and consistency across their IT
systems.
The project leader, Shawn
Mullen, IBM, joined the meeting by conference call, and gave a
presentation on the main characteristics and positioning of ACE. He
pointed out that there are many items in regulatory requirements – for
example, in PCI DSS, Sarbanes-Oxley, and ISO 27005 – which could be
automated by the ACE solution across a variety of platforms and devices
to assure compliance. It describes compliance requirements in XML,
applies the required configuration policy, and monitors and generates
alerts if it detects any non-compliant component. There is opportunity
for vendors to add value to their use of ACE in their compliance tools;
e.g., in their code representation, and in reconciling any conflicting or
inconsistent compliance requirements.
Discussion on competing
standards work identified NIST's SCAP and XCCDF (in the Government
community), PCI DSS, COBIT, and ISO27005 as particular standards groups
who we should seek to collaborate with in order to reassure these groups
that our goals for ACE as an additional standard in this space are to
avoid duplication of existing good work and to facilitate development of
a common open systems standard which complements their work.
Further discussion
concluded a set of "next step" actions:
- Invite participation
from vendors with known product interest in this space (we
already have a sec-ace@opengroup.org
email list of nine supporting members from five member organizations)
- Set up a
new web page for the project
- Generate a short (less
than four pages, preferably with good diagrams) White Paper explaining
how ACE works and delivers the claimed benefits, what systems it can
be used on, how to deploy it, and perhaps at least one real use-case
to demonstrate its application; this White Paper will provide key
collateral to attract serious interest in participation, and
reassurance to potential competitor skeptics
- Compile a contacts list
for potential additional interested parties
- Create a roadmap setting
out in priority order the development work items the project will
deliver
We will complete these action items by the time of our first project
conference call, on Tuesday November 11 2008.
The project documents are available here.
In the previous meeting (Chicago, July 2008) Ian presented a summary on the current status of this project, including
outcomes from the June 24 2008 Burton Group Catalyst Conference SIG
meeting with the MITRE CEE (Common Event Expression) project members. Our goal in collaborating with the CEE members in a joint project
moderated by Burton Group analysts Dan Blum and Bob Blakley is to find
ways to converge our XDAS efforts with that of the CEE members so as to
ensure we arrive at a single interoperable event and logging standard
that meets today's audit industry requirements for collecting and
logging events.
Since June 2008, we have made little progress with our efforts to
make progress with the CEE project members. After a further three months
elapsed time and little progress being made, we have concluded that
since we believe the industry cannot wait any longer than is necessary
for a standard on a common event record format (CERF), we should get on
with our own Security Forum XDAS project. At every stage we will
continue to participate in the CEE group and monitor the outcomes from
the CEE project, with the intention of influencing the CEE standard so
as to maintain alignment between XDAS and CEE. This is in keeping with
our intent to deliver a single industry standard for event record
formats, so ensuring interoperability for consumers of event records.
The value of achieving this is immense in our increasingly regulated and
audited IT business environment.
Our XDAS
draft has been boiled down to the essentials of an event and logging
standard, excluding the API which was in the published 2004 standard. It
now covers:
- An event record format (logline, JSON, and XML)
- An event taxonomy (for the event type as well as outcome)
- Event filtering (which probably needs to be reworked as well)
- Audit service requirements (some overlap with CEE here)
Also, in the last three weeks we have issued a new introductory chapter to
our sec-das email list, to explain the scope and purpose of constraining
the update of our XDAS standard.
We will continue to coordinate project activities with The Open Group XDAS project and members of the MITRE-led Common Event
Expression (CEE) Group, plus the Burton Group and other interested parties, to reconcile areas of known difference which
are material to assuring interoperability between XDAS and CEE.
Jericho Forum Initiatives Taken up in
the Security Forum
Trust Taxonomy Standard
Following up from our Chicago (July 2008) meeting, our Trust Management & Classification (TMC)
web page (www.opengroup.org/projects/security/tmc)
provides members with access to all the Trust Taxonomy project materials assembled to
date. In this session, members reviewed an updated presentation
reflecting review feedback from the discussion in Chicago, validating the concepts and definitions as a
necessary basis for creating a trust taxonomy upon which we can build a
trust/confidence management model. We need to write a formal Charter to
define the deliverables and timeline for this project, which has been
introduced into the Security Forum from the Jericho Forum.
Collaborative-Oriented Architectures (COA)
The Jericho
Forum has been developing a security framework for establishing secure
collaborative B2B partnering between enterprises. It has called this its
Collaborative-Oriented Architectures (COA) Framework. Members who are in
both the Jericho Forum and the Security Forum propose to bring this COA
Framework into the Security Forum as a new standards development
project. The positioning of the Jericho Forum versus the Security Forum
is well represented in the "lozenge"
diagram, which shows:
- The Jericho Forum as thought-leaders and
requirements-gatherers
- The Security Forum as the expert group on developing open systems
standards and guides which meet industry implementation,
interoperability, and potential for certification requirements
It is under this model that we plan to start a new COA Framework
project. As for the Trust Taxonomy project, we need to write a formal
Charter to define the deliverables and timeline for this COA Framework
project. We propose adopting the work already produced by the Jericho
Forum, and further papers they are currently preparing, which we believe
will substantially deliver all the materials we need to deliver the core
content, so the real task in developing this COA Framework standard will
be to:
- Validate the COA framework, using appropriate analysis methods
- Review its existing requirements-style materials and convert these
into adequate specifications for each component in the framework
- Integrate these components into a coherent framework such that it
is implementable
The initial proposal as presented in the Security Forum's January 2008
meeting was to revise the Secure Mobile Architectures Technical Study
(E041, published February 2004) to become an Open Group SMA Technical Standard. This proposal was reviewed in the April 2008 meeting (Glasgow)
where members considered which aspects of SMA were appropriate for
development as a standard interface and subsequent certification
program. Arising from this review it was agreed that the champion for
this project would draft a paper sufficient to describe:
- What is the problem being addressed
- What is the technical architecture that will solve it
- What in this architecture is common and therefore needs to be
standardized to make it interoperable in a generic environment; also, what are
the underlying assumptions
- Present at least one use-case to illustrate the potential value
The response (not in a paper) presented in our Chicago (July 2008)
meeting was that the application area has probable value in the Supervisory Control and Data Acquisition (SCADA) connectivity
infrastructure. We may therefore view SMA's application scope as lying
in resolving connectivity problems in SCADA closed environments; for example, a large manufacturing floor. This kind of
requirement will
have the interest of manufacturing enterprises. Known interest is from
Ford, Siemens, and petrochemical industries (like Exxon Mobile).
Discussion in this Munich meeting concluded that the SCADA community
are seriously concerned over the lack of security overall, including
their endpoint devices. It seems they need a migration strategy to
recover to an acceptable level, and interest in a new solution like SMA
is not therefore on their current agenda. Further extensive discussion
among a reduced number of members at the end of our Munich meeting
clarified several technical issues over the networking aspects of the
SMA proposal, but still not sufficiently well to enable us to construct
a functional diagram showing the overall operation, key functional
components, and interfaces, and where existing standards would apply to
ensure interoperable implementations, and where components/interfaces
need to be defined by a new standard. We need this overall picture to be
able to define the value that this SMA proposal is aiming to deliver.
Looking at the problem from the "attract members interest" viewpoint,
they will only buy into the project when they:
- Understand what its application area is; i.e., its
context and scope
- Understand the expected deliverable's market-positioning and benefits
- Estimate the resources, work commitment, and timeline
to completion
- See where we're starting from (what we've already
got)
- Identify where existing standards apply, and if
they're sufficient or need extending
- See what new components need defining to make it
implementable
- See which components need a standard to make it an
interoperable solution
- Understand any related dependencies and integration issues
This needs us to outline the information in one or more
infrastructure diagrams showing the key components, their functions, the
key interfaces which will make the system an open (interoperable)
standard, and how the components are interlinked. It then becomes relatively easy to
identify where the development and standards work is needed, so we can
estimate the task and understand the skills and resources we need to
deliver it.
