Specialist Task Force 341:
Development of security requirements for Resource and Admission Control
Subsystem (RACS) Release 2
Who we are:
Team Leader: Scott Cadzow
Team Members: Siv-Hilde Houmb
Why we do it:
The security development methods of TISPAN WG7 (developed
by STFs 268, 292 and 329) are derived from a goal to ensure that output ETSI
deliverables from WG7 can be used as supporting documentation in an assurance
evaluation programme such as that defined by the Common Criteria for IT Security
Evaluation (ISO 15408 [2]). A method of security standards development was
published by ETSI as EG 202 387 with supporting documents specifying how to
prepare ETSI standards as Protection Profiles and Security Targets in EG 202 382
and EG 202 383 respectively. Identified as missing in these documents from the
ETSI process was a method for preparing a Threat, Vulnerability, and Risk
Analysis (TVRA) in the context of standards development which has been corrected
in the development of ETI TS 102 162-1 [1]. In further analysing the conduct of
a TVRA new work has been identified as required in the means to write security
objectives and security requirement within Step 1 of the TVRA.
The security objectives of a system are the set of
stakeholder security goals for the system. Stakeholders are the who’s who in a
system context and may have variant preferences as to what is important
concerning security. In the TVRA where analysis is of a system with several
stakeholders having conflicting interests and preferences the role of
stakeholders is degraded to the point where only the set of common goals for the
standardisation context are taken into consideration. However, the system
perspective might be composed of the various service domains of the system and
each of these may have separate and also confliction security goals.
From the security objectives the first draft of security
requirements are derived during step 2 of the TVRA. However, the way this is
done in practise various depending on the available information on the Target of
Evaluation (ToE), which is the system or parts of a system being assessed by the
TVRA. For RACS there are some general information on the system and a
preliminary version of the RACS functional requirements available. The latter
means that one needs to go through the RACS requirements and ensure that these
are sufficiently addressed by the security objectives.
The STF will derive the security requirements for RACS,
TISPAN Release 2. The resulting sets of security requirements shall be
incorporated in WI 07026. The resulting requirements can then be used to map the
stage two functional elements to the requirements. The STF must coordinate this
work with WG7.
How we do it:
The STF shall prepare contributions to WI 07026 covering those
aspects identified in the scope.
- Security requirements development 25 days.
- Apply the methods developed by STF329 to development of
security requirements (RACS) for contribution to WI 07026
Tasks for drafting and developing RACS security
requirements:
1. Define ToE together with WG7 and RACS experts from
WG2.
2. Step 1 and 2 of the TVRA; developing security
objectives and requirements for RACS.
3. Preparation of the next steps of the TVRA.
Task for WG7 and WG2 RACS experts.
Work together with the STF on defining the Target of
Evaluation (ToE) that will be used as a basis for developing and classifying the
RACS security requirements. This involves a full analysis of the RACS functional
requirements, to be used as basis for deriving the security objectives and
requirements (using the TVRA method steps 1 and 2).
The RACS TVRA (to arrive at the complete set of RACS
security requirements) will be carried out in four iterations. The first
iteration is performed by STF 329 in cooperation with WG7 and includes Step 1
and Step 2 of TVRA (note that Step 1 and Step 2 contain a vulnerability analysis
of the security objectives and security requirements respectively). ToE
description is needed for Step 1 and 2 and WG2 should support the STF with
establishing the ToE description. Deadline is October 10th. The
result from iteration 1 will then be discussed with WG2 and WG7 in conf call
between October 10th and October 20th. Iteration 2 will be
performed in cooperation with WG2 and take the feedback from this discussion and
re-iterate Step 1 and 2. Result of the second iteration will be given as input
to and discussed at 15bis or 15ter meeting Oct/Nov. Iteration 3 will take into
account the discussions during 15bis or 15ter meeting and re-iterate Step 1 and
2. Deadline for third iteration is November 23rd. Result from the third
iteration will be given as input to and discussed during a conference call by
December 5th. The forth iteration includes taking the feedback from conference
call and re-iterate Step 1-2 taking the feedback into mind. The resulting set of
RACS security requirements will be contributed to WI 07026. Iteration four will
be completed by December 20th.
Time plan for the work:
The results of the analysis and stage 2 / stage 3
consequences are planned for discussion during a WG 7 meeting 10-11 December
2007. The STF will submit the Final Report and final draft TS 187 001 for
approval by TISPAN#16 (12-13 December).
How to contact us:
Contact stf341@etsi.org
Note: this information is based upon STF working assumptions.
The views expressed do not necessarily represent the position of ETSI in this
context.
Last updated: 2008-03-19 18:01:15