1、 - STD.ETS1 ETR 332-ENGL L77b I3900855 Olb0113 78b ETSI 1 ECHNICAL REPORT ETR 332 November 1996 Source: ETSI TC-STAG Reference: DTWNA-002509 ICs: 33.020 Key words: Security Security Techniques Advisory Group (STAG); Security requirements capture ETSI European Telecommunications Standards Institute E
2、TSI Secretariat Postai address: F-O6921 Sophia Antipolis CEDEX - FRANCE Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat Q etsi.fr Tel.: +33 4 92 94 42 O0 - Fax: +33 4 93 65 47 16 Copyright Notification:
3、 No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in ali media. O European Telecommunications Standards Institute 1996. All rights reserved. Page 2 ETR 332: November 1996 Whilst every care has been taken in the p
4、reparation and publication of this document, errors in content, typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to “ETSI Editing and Committee Support Dept.“ at the address shown on the title page. - STD-ETSI ETR 332-ENGL L77b m 3400855 OLbOLL5 557 m
5、 Page 3 ETR 332: November 1996 Contents Foreword . 5 Introduction 5 Scope 7 References 7 Abbreviations . 8 General Methodology 8 4.1 Working procedure within ETSI . 9 4.2 4.3 4.4 Simplifications and models 10 Explanation of terminology . 12 Methodology flow chart 12 Security objectives definition .
6、13 5.1 Identification of the systems nature . 14 5.2 Identification of individual security objectives 15 System review . 15 Threat analysis 19 7.1 Identification of system-specific threats . 22 7.2 Identification of threats based on external requirements . 22 7.3 Guidelines to the identification of
7、data protection threats 22 7.4 Guidelines to the identification of threats related to inter-network communication 23 7.5 Guidelines to the identification of threats to system integrity . 24 7.6 Guidelines to the identification of threats due to security policies 24 Risk assessment . 24 8.1 Evaluatio
8、n of threats and definition of risks . 25 8.2 Determine threshold for major threats respectively risks . 27 8.3 Evaluation of the global risk. risk assessment report 27 8.4 TC/STC management decision . 27 8.5 Setting up the final risk assessment report 27 Security requirements . 28 Annex A: List of
9、work items referred to in this ETR 30 History 31 Page 4 ETR 332: November 1996 Blank page STD-ETSI ETR 332-ENGL L77b 3q00855 OLbOLL7 321 Page 5 ETR 332: November 1996 Foreword This ETSI Technical Report (ETR) has been produced by the Security Techniques Advisory Group (STAG) Technical Committee of t
10、he European Telecommunications Standards Institute (ETSI). Introduction This ETR is one of a set of documents to support ETSI Technical Committees in analysing and defining their specific needs for security and in specifying the security measures that become necessary. This ETR provides guidance and
11、 support for a comprehensive analysis of threats, vulnerabilities, risks and for the compilation of a specific set of security requirements. Advice regarding working procedures and documentation is included. Page 6 ETR 332: November 1996 Blank page STD-ETSI ETR 332-ENGL L99b 3Li00855 OLbOLL LTLi = P
12、age 7 ETR 332: November 1996 1 Scope This ETSI Technical Report (ETR) provides guidance and support for a comprehensive analysis of threats, vulnerabilities, risks and for the compilation of a specific set of security requirements. It is the intention to provide the user of this ETR with a comprehen
13、sive understanding and methodology regarding threats, vulnerabilities, risks and security requirements. The security architecture of a particular system is always unique and the threats and security requirements are very specific to that system. The contents of this paper provide guidelines and chec
14、klists rather than specifying in too much detail in order to facilitate the application by the user. This ETR should enable TCs to start their security work from scratch, to take advantage of the experience from other TCs Security Experts Groups (SEGs) or to adapt solutions that have already been de
15、vised. STCs seeking advice on threat analysis and security requirements capture should ask STAG for support. 2 References , This ETR incorporates by dated and undated reference, provisions from other publications. These normative references are cited at the appropriate places in the text and the pub
16、lications are listed hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply to this ETR only when incorporated in it by amendment or revision. For undated references the latest edition of the publication referred to applies. 11 1 121 31 141 51 161 1
17、71 191 11 11 ETR 236: “Security Techniques Advisory Group (STAG); A guide to the ETSI security standards policy“. ETR 232: “Network Aspects (NA); Security Techniques Advisory Group (STAG); Glossary of security terminology“. ETR 233: “Security Techniques Advisory Group (STAG); A directory of security
18、 features in ETSI standards“. ETR 237: “Security Techniques Advisory Group (STAG); Baseline security standards; Features and mechanisms“. ETR 340: “Security Technical Advisory Group (STAG); Guidelines for security management techniques“. DTRNA-002603: “Security Techniques Advisory Group (STAG); Guid
19、elines for integrating security mechanisms into ETSI standards“. ETR 234: “Security Techniques Advisory Group (STAG); A guide to specifying requirements for cryptographic algorithms“. DTWNA-002701: “Security Techniques Advisory Group (STAG); Guidelines on the relevance of security evaluation to ETSI
20、 standards“. ETR 330: “Security Techniques Advisory Group (STAG); A guide to legislation, recommendations General UPT security architecture“. ETR 086-3: “Trans European Trunked Radio (TETRA) systems; Technical requirements specification Part 3: Security aspects“. 121 COM(90) 314 SYN 287: “Draft EU d
21、irective on the protection of personal data“. i 31 COM(90) 314 SYN 288: “Draft EU directive on the protection of personal data in digital telecommunication networks“. STD.ETS1 ETR 332-ENGL L99b 3900855 OLbOL20 9Lb I Page 8 ETR 332: November 1996 i41 CD-71-91-502-EN-C: “IT Security Evaluation Criteri
22、a (ITSEC)“. 3 Abbreviations For the purposes of this ETR, the following abbreviations apply: ACT DEF DPT ECT ED1 EU ICT ITSEC MNT RPC RT S SAGE SAT SEG SIT SRCP UPT Access Threats system or service Deficiencies Data Protection (Privacy) Threats External (inter-) Communication Threats Electronic Data
23、 Interchange European Union Internal (Intra-) Communication Threats Information Technology Security Evaluation Criteria Management Threats Remote Procedure Call Residual Threat Security feature Security Algorithms Group of Experts Threats generated by Safeguards Security Experts Group System Integri
24、ty Threats Security Requirements Capture Procedure Universal Personal Telecommunication 4 General Methodology The methodology defined here has 3 different aspects: a) working procedure within ETSI; b) simplifications and models; c) methodology flow chart. Page 9 ETR 332: November 1996 4.1 Working pr
25、ocedure within ETSI As STAG is the responsible co-ordination group for security within ETSI, it provides a set of documents about general aspects of security. STAG provides a general security policy for ETSI and gives guidance to the TC/STCs so that the work on security in each TCETC can be carried
26、out efficiently. The relationship between the different securitv workinq uroutx within ETSI is illustrated in finure 1. For further information I - of relationships between these groups, iee ETR 236 l. requirements for algorithms security policy, guidelines-+ C- security architectures I - TC- TC- .
27、L legend: CEG = Security Experts Group SAGE = Security Algorithms Group of Experts (S)TC = (Sub-)Technical Committee Figure 1 : Relationship between security working groups within ETSI Usually, when security work is started within an STC, a special SEG is set up for that purpose. A SEG consists of b
28、oth security experts and system service experts respectively. The flow of information between an individual SEG and STAG is shown in figure 2. general g u id elin es request - advice security archi- tecture request - advice systems specific- ations Figure 2:.Information and documentation flow betwee
29、n STAG, SEG and STC STD.ETS1 ETR 332-ENGL 277b m 3400855 OLbOL22 777 m Page 10 ETR 332: November 1996 4.2 Simplifications and models A large number of different methodologies can be defined for the security requirements capture. For example one possible approach is to use a special methodology for e
30、ach system. This, however, would not be efficient in ETSI where many different systems have to be investigated and duplication of work has to be avoided. The solution chosen here approaches the problem with a number of simplifications. A first simplification is to discuss security on a more abstract
31、 level. Firstly security objectives have to be defined. Then as shown in figure 3 the unverified system is put under review by setting up an abstract model of the system to allow comparison to other system models that have already been investigated. definition of security objectives - definition of
32、security properties 4 secu re d real real system world CEG work system s systems review redesgn integration level -f , sRcssessintrep,ort background STAG features i threats require- ments rn e tho do logy - - legend: SRCP = Security Requirements Capture Procedure Figure 3: ETS Security Requirements
33、Capture Procedure (SRCP) At the abstract level threat analysis and all the security specification is done by taking advantage of existing STAG documentation about generic security aspects and methodology. Finally a model of the secured system is set up that will indicate where to redesign the system
34、. The second simplification is the definition of an abstract model for the security characteristics of a system. The dotted areas in figure 4 represent a real system with its associated threats. The abstraction of the real system is realized by its description in terms of security, .e. the descripti
35、on of its technical vulnerabilities. From the opposite direction threats to those vulnerabilities are defined also at an abstract level. Page 11 ETR 332: November 1996 Leg end : system: real distributed system exposed to threats: “cloud“ of threats, constantly threats. changing and only partially S:
36、 Security feature protecting an known. individual vulnerability. V: defined individual Vulnerability of T Threat. the system. RT Residual Threat. Figure 4: Abstract model for the relationship between threats, risks, vulnerabilities, security features and residual risks Following that procedure the s
37、ecurity requirements will become apparent and security features can be defined. The model allows a one-to-one relationship of threats and security features so that the effectiveness and completeness of countermeasures can be controlled. Threats that will not, or that will only partially, be countere
38、d are identified as “residual threats“ within the model. Generally three reasons for vulnerability in a system can be identified: - design vulnerabilities, caused by design weakness of the system which can be removed by a redesign of appropriate system functions; - avoidable vulnerabilities, caused
39、by a fundamental property of the system and can be fully protected by a certain security feature; - unavoidable vulnerabilities, caused by a sensitive function of the system and for which a security feature cannot be found. In this case either the sensitive function shall be removed or the associate
40、d threats have to be accepted; - forced vulnerabilities, causes by external restrictions or requirements, e.g. legal interception and data protection issues. Resulting features have to be implemented but should be clearly identified towards the users and operators of the system. It becomes obvious t
41、hat an SRCP can initiate a lot of different activities where the specification of technical countermeasures is only part of them. As a side effect the SRCP can increase the quality of a systems design significantly. STD.ETS1 ETR 332-ENGL L79b m 3400855 Olb0124 5bL m Page 12 ETR 332: November 1996 4.
42、3 Explanation of terminology One example for a security objective could be the confidentiality of information A. A relevant threat could then be the disclosure of information A. The needed security requirement could be the confidentiality of information A. Confidentiality could be provided by a secu
43、rity feature or a security service. An appropriate security feature could then be realized with a security mechanism using, for example, the RSA algorithm. Following this example, a threat could be everything that makes a security objective unsatisfied. The security requirement could be something th
44、at helps to satisfy security objectives in the presence of threats. Finally, security features should be understood as what needs to be provided in order to meet security requirements, e.g. security mechanisms, security management techniques, etc. 4.4 Methodology flow chart Figure 5 briefly describe
45、s general steps of a SRCP. -_ -_- SEG security work START y Security Objectives definition I Systems ana lys is assessment assessment Security requirem ents specification Security features specification STAG documents: - see annex A. Figure 5: General methodology flow chart STDmETSI ETR 332-ENGL L77
46、b 3Li00855 OLbOL25 LiT8 Page 13 ETR 332: November 1996 Each distributed system has a specific profile of threats, vulnerabilities and security requirements. Depending on the internal structure and the intended tasks of the system a list of basic security objectives of a very general and generic natu
47、re should be defined before any detailed security investigation takes place. Knowing that an absolute secure system is illusory and prohibitively expensive the security objectives definition should give a clear orientation for the succeeding investigations. Before a threat analysis can be started it
48、 is necessary to understand all the attributes of the system and to define the systems boundaries where further investigations should take place. Such a “system review“ should also produce a complete understanding of the systems nature, its whole functionality and performance, in a way that potentia
49、l vulnerabilities become transparent. The succeeding “threat analysis“ comes out with a list of system specific threats that have to be categorized to prepare the following “assessment of risks“. System design deficiencies that have been recognized by SEG members, should lead to an early response to the system designers. This activity is also part of a threat analysis. The intention of “risk assessment“ firstly is to have some kind of a priority list, which threats are to be considered more severe, more important or more costly than other
