TODAF-SABSA Integration – Tutorials
See TOGAF-SABSA Integration below.
AM Plenary – Cybersecurity
See the Plenary report.
PM SPC - Security Management; Security Architectures
See the Plenary report.
Information Security Management Workshop – ISM3
Vicente Aceituno, project leader on the Information Security Management Maturity Model (ISM3) project, explained the objectives, unique approach, and positioning of ISM3 in the security management space. His ISM3 slide presentation is available to members and attendees to the conference.
The problem – the benefits of ISM3 compared to ISO 27000:
- ISM3 helps to explain/justify the value-add of the security objectives and actions that you apply in your business, and demonstrate through metrics feedback how effective those objectives and actions are in delivering those business benefits.
- ISO is now developing a maturity model in the 2700x series, so we will want to align with that when it is available.
- ISM3 protects business objectives rather than just focusing on business assets.
- ISM3 uses positive terms and positive measures for its processes because you can only manage positive things – negatives cannot be measured or managed.
- ISM3 uses operational definitions for security – switching from "what is something" to "how do you measure something"; e.g., you don't need to understand "mass" to measure the weight of something.
The ISM3 approach promotes continuous improvement through repeated assessments from measurements on key process capabilities, and selecting which metric types best support which levels of process capability. The more metrics supporting a capability level, the more capable is the process.
Maturity levels are not yet defined for ISM3, but ISM3 aims to support a security management maturity level scheme based on low/medium/high benefits delivered through selected levels of (low/medium/high) investment. Businesses will decide which ISM3 processes are high/medium/low value to their business objectives, and will then assess the investment required to deliver each one to arrive at an implementation plan that matches their business objectives for security against their funding/resources to deliver it.
Next steps include:
- ISM3 Maturity Levels - specify a set of meaningful ISM Maturity Levels for ISM3 adopters/implementers.
- Market for ISM3 Certification – investigate sufficient market appetite/interest (e.g., three highly qualified organizations) in business organizations who wish to achieve certification for their ISM3 implementations and are ready to apply for ISM3 certification. Current understanding of the market demand for ISM certification is that ISO 9000 for "quality management systems" is high; by comparison, ISO 27000 certifications for "information security management systems" are much lower. We need to assess certifications for ITIL and CobIT. Based on determining a sufficient market for ISM3 certification, we will develop an Open Group ISM3 certification program based on the ISM3 standard and associated Maturity Levels specification.
Identity Management
In this meeting session, members reviewed two areas of recent work on Identity Management put together by the Jericho Forum, as information on what IdM requirements might interest Security Forum members in developing related standards and best practice guides responding to those requirements:
- Future Major Security Challenges:
The Jericho Forum has held several "blue-sky thinking" sessions recently, aimed at gathering members' ideas on the main security challenges they forsee will raise major challenges to information security in the next two to five-year timeframe if security vendors and solutions suppliers are not influenced now to work on developing effective solutions and bringing them to market. They are currently reviewing seven challenge items, and they plan to mainline on two of them. Members can review these blue-sky challenges and the two favored items here (member log in required).
- Identity Principles:
Another recent exercise by Jericho Forum members was to devise a set of "security principles" – assertions which capture key features that characterize "identity". The purpose of this is to ensure we have a set of features against which we can test how well the existing and any new identity management solutions satisfy these identity principles. This list was shared with the Security Forum members so as to raise awareness on this work, and also to invite their expert feedback, as part of a process to consolidate the list into a jointly-agreed set of identity principles. As for the "blue-sky" challenges, members can review these here (member log in required).
Trusted Technology Forum
Andras Szakal gave a presentation (see slides) on the formation of the new Trusted Technology Forum in The Open Group.
In 2009, the US Department of Defense supported The Open Group in establishing the ACS Initiative, an industry-wide effort where vendors could identify the current best practices and processes that contribute to the creation of trusted technology and trusted technology providers. Toward that end, the Initiative set about creating the Trusted Technology Provider Framework (TTPF) that identifies those best practices and product assurance standards. The initiative also explored the formation of a program to identify those providers and technologies that follow the best practices in the TTPF. They developed a TTPF White Paper that explains the business value for all stakeholders in creating such a program.
As the ACS Initiative wraps up this deliverable, the level of support from ACS participants and Open Group members for continuing the work of this group, including adding formalization in governance, management, and support, has become clearly evident. Consequently, the group is transitioning from the ACS Initiative to become a new Forum under The Open Group. This Trusted Technology Forum will continue identifying best practices that, when applied cohesively and appropriately, will translate into a level of assurance that can be communicated to customers. It will benefit both the supplier and buyer communities: giving suppliers accepted industry-common targets to aim for; enabling buyers to more easily identify products and providers that meet secure, trusted development, and manufacturing quality; and assuring supply-chain best practice criteria. Vendors investing in and conforming to these practices and processes may expect to gain a deserved market differentiation.
Security Forum Strategy/Planning Review
This review included assessing the value of past and forthcoming security deliverables into a map of cohesive contributions to addressing key areas of information security where standards and best practice guides clearly add value to improve quality of implementing effective and complete solutions and enable building of solutions that are interoperable.
Discussion moved in a direction addressing how well or otherwise we present the map of information space that we aim to cover. Currently our strategy is to direct our interests into two streams – Security Architecture and Security Management. Are these two categories sufficient? How can we represent diagrammatically how our past and forthcoming deliverables fit into these two categories so they reflect not only where they contribute but also how significant we judge their value/contribution/impact to be. Discussion ranged over histograms, quadrants, and more complex geometric shapes, bubble diagrams, and more. We will take the feedback from this discussion into our Security Steering Committee, to decide how best to move this item forward.
Security Addition Proposed for TOGAF 9
Members reviewed the "Integrating Security into TOGAF ADM" paper originally passed to the Architecture Forum chairman (Dave Hornford) in February 2010. We reminded ourselves that the Architecture Forum strongly recommended we submit our proposed changes in a specific change request format that the Architecture Forum are accustomed to using.
Specific additions we should consider adding to this list of proposals include:
- Referencing ISM3 in our project to integrate security into TOGAF and SABSA
- Referencing our Risk Taxonomy standard in TOGAF Chapter 21 (Security Guidelines)
- Referencing our Secure Mobile Architectures draft standard in TOGAF
- Appreciating the potential outcome of what could be in comparison with “what currently is” – intermediate architectures – we need to fulfil the security requirements all along the development path.
- Considering the value of penetration testing as part of vulnerability testing; for applications, this fits under white box & black box testing
See also the progress reported in the TOGAF-SABSA Integration project below.
TOGAF-SABSA Integration
Sunday Tutorials
This project involves members from the Architecture Forum, the SABSA Institute, and the Security Forum. Its members began serious work by holding a level-setting tutorial session on SABSA to inform TOGAF members, and on TOGAF to inform SABSA members.
Monday Key Messages
This project involves members from the Architecture Forum, the SABSA Institute, and the Security Forum. Its members began serious work by holding a level-setting tutorial session on SABSA to inform TOGAF members, and on TOGAF to inform SABSA members. In this session, members confirmed they would approach the project goals by running six streams:
- Common glossary for TOGAF & SABSA: For communication we need to speak the same language, including harmonizing with other standards we will wish to reference: ISM3, Risk Taxonomy, Cookbook for ISO 27005, and external standards (ISO, COSO, Octave, etc.).
- Form definition: How to position SABSA within the TOGAF architecture meta-model. How to integrate both frameworks.
- Make SABSA accessible from TOGAF ADM: TOGAF Phases A-E can map to SABSA layers; mapping of SABSA elements to deliverables, artifacts, and building blocks.
- How to integrate TOGAF and SABSA (i.e., make TOGAF accessible from SABSA). Viewpoints – each view can have different business drivers; this includes defining a baseline and target security architecture; also includes scoping.
- Requirements management: what will be the added value of using the SABSA business attributes concept as a model for TOGAF requirements management?
- Synchronize with current Open Group security initiatives for integrating security into TOGAF: Security Architecture issues that we wish to integrate into the TOGAF ADM, and architecture issues we wish to integrate into SABSA.
Monday SPC Track
Presentation (available to members only) by John Sherwood (Principal, SABSA Institute) in the Amsterdam Security Practitioners Conference (SPC) Track, on a SABSA Primer for the TOGAF-SABSA Integration project, inviting member participation in this project, starting with a workshop at the Amsterdam conference on Wednesday October 20.
Wednesday Project Workshop
Members agreed appointments of stream leaders and contributors, approved an outline structure for the project white paper deliverable, agreed to prioritize streams C, D, & F for development aimed at approving them for incorporation in to the draft white paper as part of our San Diego meeting agenda, and began work on framing content/structure in the selected C, D, & F streams. Members agreed to run three-weekly progress conference calls beginning November 11 to facilitate project-wide review in contributing to achieving the target completion of streams C, D, & F in the San Diego meeting.
Cloud/SOA Security, joint with CCWG
In this joint workshop with the Cloud Computing “Security for Cloud & SOA” group, members reviewed progress, guided by the co-chair of the Cloud Computing Work Group Security sub-group.
The issues being addressed by the Cloud/SOA Security project are listed in a ToC (see slides, available to members and attendees only). Recognizing that many other groups are also addressing this space, the major item missing from what other groups are addressing in Cloud Security is Reference Architecture – the cloud ecosystem comprising suppliers and consumers. Security architecture principles and Jericho Forum commandments were discussed, along with work on security requirements (use-cases, non-functional requirements; policy & compliance issues including export regulations; privacy; where the data is located, differentiated by country), and tolerance/acceptance of risk. An action to specifically address security policy & compliance issues in a special conference call in November was agreed. Security monitoring, audit, and logging are also key considerations – in Cloud and SOA.
The SOA reference architecture and position of security within it was reviewed, in the context of an ecosystem model and building blocks within it. The OASIS "Identity in the Cloud" project is being monitored as a component for including in the model. In this review, it is important to recognize that the goal is to raise awareness of the additional security challenges end-to-end, raised by operating in environments where we have distributed applications, services, and data.
Considering how to record and process candidate architectural decisions, while TOGAF gives guidance on architectural principles and recognizes that architectural decisions are important, it does not provide a template for recording how to arrive at ADs, how you capture the rationale for those decisions, and how you express them for future use. Accordingly, IBM has suggested we may like to adopt their Architectural Decision Template as a suitable mechanism. Members expressed interest in following up on this, so IBM accepted an invitation to run an “Architectural Decisions Rodeo” in the next conference (San Diego, February 7-11, 2011).
Secure Mobile Architecture (SMA), joint with RT&ES Forum
This is a joint Security Forum and Real-Time & Embedded Systems (RT&ES) Forum project. Slides summarizing the issues discussed in this session are available to members and conference attendees. After a brief summary on the goals of this project, and on the significant progress made at the previous conference (Boston, July 2010) in creating SMA draft 0.7, the project leader, dialling in to the Amsterdam conference along with three of the four main contributors to draft 0.7, initiated discussion on three significant development issues:
- Identity & identifiers:
What do we standardize? Over/across what domains? Who are the authorities? How do we handle hierarchical delegation? How do we make this usable and scalable? What works for individuals and large enterprises? Discussion mentioned DNS, distinguished names, MAC-Id, addresses in IPv4/6, PKI, HIT, and more. EPC, ISBN, and Bank Routing were also mentioned as desirable compatibility requirements to make SMA identity friendly to other global communities. This is a core issue, so action was agreed to move it forward through a problem statement and call for member feedback.
- Lookup-service options:
Which services should we include? Possible services include Local Configuration File (e.g., /etc/hosts); NIS/YP; LDAP / AD; RDBMS; IF-MAP. Each service has relative (dis)advantages. Also how do we ensure interoperability? Again, action was agreed to move it forward through a problem statement and call for member feedback.
- Interoperability goals:
Should any two implementations fully interoperate? Implications include adding carefully detailed specification, mandatory IOP versus optional IOP features, interoperability testing, and certification. The approach to these issues requires starting from an architectural framework view of SMA and identifying where in the framework are the common components that we must make standard. We will then target these for interoperability and then evaluate the “glue” that ties the SMA solution together.
Checking our revised schedule for this project, final SMA review is now aimed for July 2011.
Further writing topics include Middlebox for PEP functions; cryptographic methods selection; identifier namespaces & delegation; and lookup-up service interoperability & integration. We will invite members to contribute to these topics and also to our three development issues listed above.
