STFbreadcrumb separatorSTFsbreadcrumb separatorSTF Homepagesbreadcrumb separatorSTF341

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:


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