Introductions & Agenda Review
After a round of introductions, the agenda was approved.
Review Security Forum Current Positioning & Status
Members reviewed a summary
of where we are today, and what opportunities we have for improving the
value-add of the Security Forum to IT-dependent enterprise businesses.
The presentation focused on the first five slides - covering where we are
today in our overall Open Group security program, which embraces:
The remainder of the slides in this presentation cover the origins, evolution, achievements,
and current projects in the Security Forum.
One suggested new project is to pull together a Guide for Security
Architects to include our work on design patterns, building blocks,
views, governance, etc.
Action: Ian will gather existing sources of materials which may
contribute to a useful Guide for Security Architects.
Another suggested project not covered as a separate agenda item is an
opportunity to engage with the organizers of the "Global Security Challenge" (London Business School),
which aims to promote development of innovative security solutions for today's global IT
environment, through running a competition where contenders submit
proposals for solutions, judged by an expert panel with potential for
venture capital support for the winner(s). The benefit to the Security
Forum in becoming involved was thought to be minimal, though the
beneficial visibility for The Open Group to support organizing this
event (in October - the week before The Open Group q407 conference) may be worth
investigating. We could look at the impact on enterprise architectures -
a message to start-up solutions developers that successful deployment
paths are greatly eased if the proposed solution fits into an existing
framework. We could see if we can make enterprise architecture a part of the challenge. Maybe
we could suggest how to develop solutions beyond just technology (i.e.,
people and process too). Or participate on a panel - even the panel of
judges.
Action: Ian will include in the Security Forum q407 agenda a report
on the outcomes (entries, winner, etc.) of the Global Security
Challenge.
Security Forum Strategy White Paper
This is an Open Group Security Forum White Paper, prepared in collaboration with the American Bar Association Cyberspace Law Subcommittee on Connectivity, Storage, and Computing Infrastructure Security, and with contributions from The Open Group’s Jericho Forum.
It proposes a strategic direction for further new multi-disciplinary projects targeted at advancing the role of the Security Architect in support of delivering better governance.
The latest draft of the document is available to members at www.opengroup.org/projects/sec-strategy.
Arising from our continuing collaboration with the American Bar
Association's cyberlaw group, the visit of our Chair to the ABA Winter
Meeting last week resulted in much interest from ABA cyberlaw group
members, and an undertaking that a prominent ABA cyberlaw group member
will send us a revised draft based on the review in their meeting.
The Security Forum members took a guided tour through the latest
draft of the paper. Comments were mostly observations stimulated from
the content but not proposing any additions or modifications, except as
follows:
- Investment is also important in the information, both in its
storage and in its availability for use - hence the presentation
medium (hardware) and environment is still important.
- Coherence and commonality is emerging on how governance needs to
be practiced.
- We need security as a property of the IT system, but we also
need security of the information, which needs to be both
appropriately secure and appropriately accessible.
- Access should be automatically enforced and only relaxed when
built-in exception controls trigger a mechanism to modify it.
Identity Management
The Identity Management Forum meeting was attended by all the
Security Forum members, and is reported separately.
APC Stream #9 (Wednesday January 31)
The Security Forum organized and hosted this one-day open meeting as a
Stream of the Architecture Practitioners Conference, on the
evolving role of the Security Architect in the context of responding to
business imperatives, not only for operational security but also for
audit and support to demonstrating compliance with applicable
regulations. The agenda of presentations, synopses for each
presentation, and speaker biographies together with a report on this
very informative event are available here. The presentations
from this APC Stream #9 are available
to members-only here.
Review of FAIR (Factor Analysis for Information Risk)
The Security Forum members received a more detailed description of
the core operational features of the FAIR framework, covering risk
taxonomy, determining vulnerability, risk posture and risk management
capabilities, and the underlying management framework. Risk Management
Insight (RMI) believes that
risk management is not understood correctly; in CISSP, it is defined as
annual loss expectancy.
Members then discussed options for adopting FAIR as a new project and
what the benefits would be to each side - the Security Forum on the one
hand, and the developers from RMI on the
other. RMI's approach is to teach people how to use FAIR and then
provide them with the tools to make it work well for them; also their
stated goal is to provide the right training, backed by a certification
scheme for those who attain proficiency in using it at selected levels.
RMI have already developed training courses and an associated
certification scheme for successful trainees. Security Forum members
wondered about where FAIR fits with TOGAF - perhaps at the early stage
where business considerations are gathered.
If the FAIR framework is in the public domain, then it must be free
to use. It was confirmed that the framework is zero cost to use, and anyone
who wishes to build an implementation is free to do so ... this option
is itself an example of risk management. RMI have released the FAIR
Framework into the public domain under a "creative commons"
license, the intent of which is to ensure that anyone who develops an
enhancement is obligated to shared it with the FAIR development
community. More information on this and other aspects of FAIR are
available at www.riskmanagementinsight.com
or at the WIKI site www.fairwiki.riskmanagementinsight.com.
Discussion moved on to consider what the Security Forum would
do if we reach mutual agreement to adopt FAIR as a new project:
- Standardize/normalize terms and definitions in risk management
- Evolve FAIR in a public way:
- The Open Group to contribute to evolution
- Promote, market, adopt
- Relationship to TOGAF
- Extend to other areas; e.g.:
- Disaster/BRP...
- Project management
- ABA/legal
- Auditors
- Architecture Forum
- Training and certification are out of scope for
the present, but should be revisited at appropriate time in the
future
- Within next six months, build and validate interest
(10-20 heavy lifter contributors) of members in the Security Forum
and Jericho Forum in supporting development of an open standard
for FAIR
- Get a slot in the July 2007 Austin plenary under
"integration of TOGAF with other industry standard bodies of
knowledge in the IT field"
- Track in July 2007 to raise the challenge: existing
users, case studies, tutorial, compare with competing approaches
- Put on agenda for the next Jericho Forum BoM
meeting
- Propose putting presentation on agenda for the next
Jericho Forum Members Meeting (March 16, London) - one-hour remote
presentation
- Propose presentation to ABA Spring meeting, under The Open Group liaison arrangement
- Resolve any procedural issues that may affect The Open Group's ability to proceed with adopting the FAIR Framework by the July 2007
meeting:
- Mike will draft an email covering this to the
Security Forum membership
- Ian will draft an email covering this to the
Jericho Forum membership
Based on this approach, RMI proposed supporting the Security Forum
adopting FAIR as a new project, and the Security Forum accepted the
proposal, conditional on RMI becoming a member.
Action: Ian will coordinate the proposed program of activities
towards building an effective development project for the FAIR framework.
Security Aspects of SOA
The purpose of this joint meeting with the Service Oriented
Architecture WG (www.opengroup.org/projects/soa) was to explore
what is different about delivering secure IT operations in an SOA
environment. We held an initial discussion in the previous conference
(Lisbon, October 2006), so this is a continuation from that exploratory
meeting. In Lisbon the Security Forum outlined Jericho Forum issues, including its papers on Inherently Secure Protocols & Architectures for
de-perimeterization, to illustrate the different approach that effective
security solutions in distributed IT environments requires. The Security Forum wants to understand how SOA will support secure operations, including in the Jericho Forum’s de-perimeterization environment,
and we anticipate the SOA Working Group will similarly want to ensure SOA environments include effective security.
Additionally, both the Security Forum and the SOA WG are addressing
"governance" - so is there common ground here that again we
might share to avoid duplicated effort?
The Security Forum presented a few slides on the
Jericho Forum's de-perimeterization approach to effective IT security,
and identified position papers it has published which explain the
challenges and suggested high-level requirements for resolving them.
This was illustrated by using the secure protocols paper as an example.
The discussion developed organically into reviews of access zone
concepts and multiple access zones as a possible future infrastructure
architecture. OK - SAML and XACML define the protocols, but these are
security mechanisms; we don't have any proven models for how to
implement them, especially when we do not have a clear understanding on
what SOA "services" do - are they agents controlling access to
the resource, or the actual resource, and how do you handle chaining
where one resource needs to access another resource to deliver the
required application functionality? Aggregation raises major issues.
Every time you integrate applications, this (access control) security
decision process is needed. It is not specific to SOA but it is
essential in SOA. To understand the challenges we need to remind
ourselves of the fundamental access control model where enforcement
points (PEP) provide the required controls. Discussion brought out the
experience of how some members have implemented solutions.
An incomplete list of key issues was started, but got curtailed by
lively discussion taking another direction. The following issues were
captured:
- Audit problem - who uses the service? How is the decision made to
permit access? Do you need to record the access for audit purposes
(including non-repudiation)?
- Are you permitted to use this service? What is the access
control - policy and PEP?
- A service is often the means (agent) to get to the resource, so is
it sufficient simply to protect the service? Do I need also to
protect the resource? How do we implement this chaining control?
- What are the decision points in an SOA where security services
need to be applied?
- Risk and liability as one of the attributes - in a distributed
environment, which service accepts liability? Can I trust the other
party to give the service I expect/need? Control at a distance is
hard, unless you pass authorization though some agreement mechanism
down the chain. How should this be done?
- Classification of services - not all services need security -
WSpolicy.
The outcome was agreement that we all need to understand more about
the problems, and find out what current best practice is, so let's go
and look:
Action: All will investigate how other groups active in the SOA
world are addressing the issues raised in the joint SOA/Security session
in San Diego, and share their findings at the next conference.
No time was left for discussion on governance issues, but a
preliminary discussion indicates that the SOA governance issues are more
internal-procedural than the Security Forum's interest on how good
security can support corporate audit and compliance to regulatory
regimes.
Security Forum Joint Working with Jericho Forum
The Jericho Forum has produced several position papers which present
in relatively brief statements the problems they see are different for
IT security in boundaryless (de-perimeterized) environments compared to
bounded environments. These papers follow a consistent structure which
describes the problem, why you should care, the suggested direction for
solutions, the rationale for coming up with that suggested direction,
and the challenges this raises. These papers do imply
"requirements" for changes to the way security products work
today, but at a level which is too abstract/conceptual and high-level to
be good enough for the product supplier and solutions provider to
immediately understand, and the supplier membership in the Jericho Forum
has not so far stepped up to the challenge to provide this translation.
The Security Forum members are well qualified to do this correctly, so
Ian invited them to consider taking this up as a Security-Jericho
cross-Forum project that will deliver significant value to both
Forums.
Discussion included some sadness that the Jericho Forum is not
accepting the task to communicate effectively with the IT security
supply-side to achieve its goals, and they agreed the need to present
suppliers with clear requirements, proposals for migration of products
rather than demands for new ones, and clear demonstration of market value
and costs for undertaking development work on improved solutions for
de-perimeterized environments. We could take up a project on this, based
on interpolating and extrapolating a ghostly image for what the overall
architecture should look like to fit the requirements we might draw out
by reviewing the Jericho Forum position papers. This was agreed:
Action: Members accepted assignments to review specific Jericho
Forum position papers, with the aim of extracting content that can be
converted to actionable statements specifying realistic IT security
requirements.
