Integrating Security into TOGAF (Joint with Architecture
Forum)
Arising from a joint Security and RT&ES Forums meeting in San
Francisco (November 16-18 2009), the Architecture Forum invited the Security
Forum, RT&ES Forum, and SOA Work Group to a morning of discussions on their
requirements for architecting Security, High Assurance (RT&ES), and
SOA,
respectively. As preparation for this joint session, members of the Security Forum,
RT&ES Forum, and
SOA Work Group had discussed their differing requirements and
objectives in a series of conference calls leading up to this Seattle
meeting, to understand respective requirements and identify common interests in using
TOGAF 9 to create
architectures for their respective Security, Rt&ES, and SOA
areas. Each had prepared a short presentation of their needs from
TOGAF. Mike Jerbic gave the Security
in TOGAF presentation, which noted that the Security Forum's problems
with using TOGAF for developing effective architectures for security are
twofold:
- The need to integrate “security” design into TOGAF by
highlighting in a draft paper the key places in TOGAF 9 where it recommends
security-relevant issues that are critical inputs to the architecture
being developed should be explicit statements in the relevant ADM phases.
This draft paper also makes recommendations on revising the security coverage in
Sections 21 and 35
to make them more meaningful to architecture practitioners by restructuring and revising them.
The Security Forum believes that these proposed changes will not materially increase the
TOGAF 9 page count; in fact, restructuring Sections 21 and 35 may reduce the final page count.
- The need to also be able to architect the “uncertainty” characteristics of security.
We noted that IT architects concentrate on intentional design functions;
architecting security also needs to not only address issues of risk, quality, reliability,
and usability,
but also issues of variance – uncertainty – which needs to be managed.
So architecture consists of both intentional design and management of uncertainty,
and security architects need an architecture development method that
extends TOGAF's existing methodology to address this.
Subsequently in the Security Forum members' meeting, the members
reviewed draft input identifying
further the key places in TOGAF 9 where security-relevant issues that are critical inputs to the architecture being developed should
be brought out as explicit issues in relevant ADM phases.
Both the Architecture Forum and Security Forum members will review
the feedback gleaned from sharing viewpoints in the meeting discussion,
and consider how best to take these Security Forum requirements forward.
Security for SOA Guide (Joint with SOA Work Group)
In Q408 the SOA Work Group confirmed its intention not to publish the
submitted 13-page SOA Security document as an additional chapter to the
existing SOA Source Book. Instead, the co-authors of this work were
requested to contribute an extended chapter on SOA Security for
inclusion in Version 2 of the SOA Source Book which was aimed for
delivery in April 2009. Priorities and plans in the SOA Work Group
subsequently changed to focus on developing an SOA reference
architecture.
Since then, implementation experience on securing SOA has been
captured in a presentation which highlighted key security issues and how
they were resolved. This joint meeting with the members of the
Security Forum and SOA Work Group established a sound basis for resuming the
previous effort to develop a Security for SOA Guide.
Tony Carrato (IBM) gave a presentation
based on his experience over the past 12 months on developing SOA
architectures, highlighting the security consideration that he has found
important. His presentation includes valuable references.
Secure Mobile Architecture (SMA) Standard (Joint with RT&ES Forum)
The Security Forum and RT&ES Forum share interest in developing an SMA
standard based on the
published February 2004 SMA Technical Study. In a joint meeting on
November 16-18, members of these two Forums began joint work on a project aimed
at analyzing the real requirements and audience(s) for an SMA standard,
starting from a draft Charter which was created largely by project
leader Steve Venema (Boeing). This draft Charter is available to
members on the SMA project
web page.
Steve gave an opening presentation
to set the current status and direction he proposes.
In this Seattle meeting, members approved minor additions to the
CMA Charter, and then invited project members to contribute use-cases
based on their mobile requirements in real-life application areas, from
which we will expect to derive a set of common requirements that an SMA
standard has to meet. Steve proposed a template for filling in
each use-case. A set of nine proposed use-case topics was assembled,
and a timeline also agreed for bringing them together. Members not
present in the meeting will be invited to add their use-case
contributions to our list. All these project resources are
available to members on the project web page. Progress between
this Seattle meeting (February 2010) and the next meeting (Rome, April 26-30)
will be encouraged in a series of conference calls to assure common
understandings and share ideas.
Ecosystem for Security Guide
David O'Berry gave a presentation
confirming our action plan for delivering the first phase of this
project, the overall goal being to explain the basic information
security measures that users of IT systems in Small, Medium, & Government Businesses
(SMGBs) with no in-house professionally
trained security specialists can cost-effectively set up their IT systems in ways that
make them acceptably secure for business collaborations with larger
enterprises, and so make them more acceptable as business partners.
The approach is to set up three parallel sub-groups, to maintain focus on
the three core actors in information security – people, process, and
technology – so as to maintain clear focus on practical solutions in each topic area.
We will aim to conduct a member survey in each of these sub-groups, to priorities addressing the real pain-points and concerns.
We recognize that much is already published in this area, but a lot of it is not easily taken on board because it preaches general “good ways to do things”, ignoring practicalities of time pressures,
and knowledge of how to implement the important measures, and where to
obtain the resources to install and configure them. Measures of
our success will include testing to assess whether each measure is reasonable, practical, seen as sensible/proportionate, and a natural part of their way of working.
Risk Management Cookbook Guide
We have delivered the Risk Taxonomy Standard and the Risk Assessment
Methodologies Technical Guide. The third deliverable in our initial list
is a Cookbook – to demonstrate how the FAIR (Factor Analysis for
Information Risk) complements other less rigorous enterprise risk
assessment methodologies – with the aim of producing more valuable
results. Project leader Alex Hutton assisted by Chris Carlson (Boeing)
and Anastassia Gilliam gave a summary
presentation on the almost-completed draft
Cookbook, which describes how the FAIR taxonomy and methodology can be
applied to ISO 27005 to:
- Reconcile definitions
- Translate the FAIR Risk Taxonomy into ISO 27005 terms
- Perform risk estimations by applying the FAIR Risk Taxonomy using
ISO 27005 terms
and so deliver more rigorous and therefore more valuable risk
assessment results.
Further cookbooks
could address OCTAVE (from CERT) and NIST's 800-53. However, this first
Cookbook demonstrates how professional security assessment practitioners
can apply the same approach to
apply the FAIR Risk Taxonomy to other methodologies and so develop their own FAIR
cookbooks.
This Cookbook completes the final deliverable in our originally
planned set of three Risk Management deliverables.
Enterprise Security Architecture, Version 2 Guide
The “ESA: A Policy Driven Architecture” Guide was
a publication produced in 2004 by the Network Application Consortium (NAC).
It focused on IT Security Governance, Architectural Design, and
Operational Strategies, to answer the questions on why security
is important, how security is effectively implemented across the
enterprise, what drives security, and how it should be enforced.
The aim was also to influence vendors to address
security across the enterprise.
We have defined a Statement of Work for updating the ESA Guide, and
placed a contract with a security architect consultant to deliver recommendations
on what parts of this ESA Guide require updating, what new information
is required, and where we should obtain it.
The project Charter, available along with
background information, objectives, and deliverables, are all available
from the project web
site.
Automated Compliance Expert Standard
The project leader (Shawn Mullen, IBM) followed up his SPC
presentation on ACEML by highlighting in his presentation
key features of this standard, which is almost complete. The ACE
White Paper explains the goals of this standard – to enable products to
be developed which can apply a security configuration policy to a broad
range of IT systems (from general-purpose computers to routers and
firewalls) – and provide continual monitoring to raise an alert if any
component/device in the system falls out of the prescribed compliant
state.
