ITU-T E 409-2004 Incident organization and security incident handling Guidelines for telecommunication organizations (Study Group 2)《事故管理组织和安全事故处理 电信组织指南-第E-电话网络和ISDN操作 编号 路由和移动服务和.pdf

《ITU-T E 409-2004 Incident organization and security incident handling Guidelines for telecommunication organizations (Study Group 2)《事故管理组织和安全事故处理 电信组织指南-第E-电话网络和ISDN操作 编号 路由和移动服务和.pdf》由会员分享，可在线阅读，更多相关《ITU-T E 409-2004 Incident organization and security incident handling Guidelines for telecommunication organizations (Study Group 2)《事故管理组织和安全事故处理 电信组织指南-第E-电话网络和ISDN操作 编号 路由和移动服务和.pdf（22页珍藏版）》请在麦多课文档分享上搜索。

1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T E.409TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (05/2004) SERIES E: OVERALL NETWORK OPERATION, TELEPHONE SERVICE, SERVICE OPERATION AND HUMAN FACTORS Network management International service statistics Incident organization and security incident hand

2、ling: Guidelines for telecommunication organizations ITU-T Recommendation E.409 ITU-T E-SERIES RECOMMENDATIONS OVERALL NETWORK OPERATION, TELEPHONE SERVICE, SERVICE OPERATION AND HUMAN FACTORS INTERNATIONAL OPERATION Definitions E.100E.103 General provisions concerning Administrations E.104E.119 Gen

3、eral provisions concerning users E.120E.139 Operation of international telephone services E.140E.159 Numbering plan of the international telephone service E.160E.169 International routing plan E.170E.179 Tones in national signalling systems E.180E.189 Numbering plan of the international telephone se

4、rvice E.190E.199 Maritime mobile service and public land mobile service E.200E.229 OPERATIONAL PROVISIONS RELATING TO CHARGING AND ACCOUNTING IN THE INTERNATIONAL TELEPHONE SERVICE Charging in the international telephone service E.230E.249 Measuring and recording call durations for accounting purpos

5、es E.260E.269 UTILIZATION OF THE INTERNATIONAL TELEPHONE NETWORK FOR NON-TELEPHONY APPLICATIONS General E.300E.319 Phototelegraphy E.320E.329 ISDN PROVISIONS CONCERNING USERS E.330E.349 INTERNATIONAL ROUTING PLAN E.350E.399 NETWORK MANAGEMENT International service statistics E.400E.409 International

6、 network management E.410E.419 Checking the quality of the international telephone service E.420E.489 TRAFFIC ENGINEERING Measurement and recording of traffic E.490E.505 Forecasting of traffic E.506E.509 Determination of the number of circuits in manual operation E.510E.519 Determination of the numb

7、er of circuits in automatic and semi-automatic operation E.520E.539 Grade of service E.540E.599 Definitions E.600E.649 Traffic engineering for IP-networks E.650E.699 ISDN traffic engineering E.700E.749 Mobile network traffic engineering E.750E.799 QUALITY OF TELECOMMUNICATION SERVICES: CONCEPTS, MOD

8、ELS, OBJECTIVES AND DEPENDABILITY PLANNING Terms and definitions related to the quality of telecommunication services E.800E.809 Models for telecommunication services E.810E.844 Objectives for quality of service and related concepts of telecommunication services E.845E.859 Use of quality of service

9、objectives for planning of telecommunication networks E.860E.879 Field data collection and evaluation on the performance of equipment, networks and services E.880E.899 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. E.409 (05/2004) i ITU-T Recommendation E.409 Inci

10、dent organization and security incident handling: Guidelines for telecommunication organizations Summary The purpose of this Recommendation is to analyse, structure and suggest a method for establishing an incident management organization within a telecommunication organization involved in the provi

11、sion of international telecommunications, where the flow and structure of an incident are focused. The flow and the handling are useful in determining whether an event is to be classified as an event, an incident, a security incident or a crisis. The flow also covers the critical first decisions tha

12、t have to be made. Computer crime follows in the wake of the heavily increased use of computers in international telecommunications. Over the last years, computer crime has literally exploded, as confirmed by several international and national surveys. In the majority of countries, there are no exac

13、t figures on the number of computer break-ins or security incidents, especially those related to international telecommunications. Most telecommunication organizations or companies do not have any specialized organization for handling Information and Communication Networks (ICN) security incidents (

14、although they may have a general crisis team for handling crises of any type). When an ICN security incident occurs it is handled ad hoc, i.e., the person who detects an ICN security incident takes the responsibility to handle it as best as (s)he can. In some organizations the tendency is to forget

15、and cover up ICN security incidents as they may affect production, availability and revenues. Often, when an ICN security incident is detected, the person who detects it does not know who to report it to. This may result in the system or networks administrator deploying a workaround or quick fix jus

16、t to get rid of the problem. They do not have the delegated authority, time or expertise to correct the system so that the ICN security incident does not recur. These are the main reasons why it is better to have a trained unit or group that can handle security incidents in a prompt and correct mann

17、er. Furthermore, many of the issues may be in areas as diverse as media relations, legal, law enforcement, market share, or financial. When reporting or handling an incident, the use of different taxonomies leads to misunderstanding. This may, in turn, result in an ICN security incident getting neit

18、her the proper attention, nor the prompt handling, that is needed in order to stop, contain and prevent the incident from recurring. This may lead to serious consequences for the affected organization (victim). To be able to succeed in incident handling and incident reporting, it is necessary to hav

19、e an understanding of how incidents are detected, handled and resolved. By establishing a general structure for incidents (i.e., physical, administrative or organizational, and logical incidents) it is possible to obtain a general picture of the structure and flow of an incident. A uniform terminolo

20、gy is the base for a common understanding of words and terms. Source ITU-T Recommendation E.409 was approved on 28 May 2004 by ITU-T Study Group 2 (2001-2004) under the WTSA Resolution 1. ii ITU-T Rec. E.409 (05/2004) FOREWORD The International Telecommunication Union (ITU) is the United Nations spe

21、cialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on

22、 a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid do

23、wn in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication

24、 administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory

25、provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attent

26、ion to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others

27、outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent th

28、e latest information and are therefore strongly urged to consult the TSB patent database. ITU 2004 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. E.409 (05/2004) iii CONTENTS Page 1 Introduction 1 1

29、.1 Scope 1 1.2 Definitions 1 1.3 Rationale. 2 2 System description 3 2.1 Structure and flow 3 2.2 Incident flow. 5 3 Incident handling system 12 BIBLIOGRAPHY 13 ITU-T Rec. E.409 (05/2004) 1 ITU-T Recommendation E.409 Incident organization and security incident handling: Guidelines for telecommunicat

30、ion organizations 1 Introduction 1.1 Scope The purpose of this Recommendation is to analyse, structure and suggest a method for establishing an incident management organization, within a telecommunication organization involved in the provision of international telecommunications, where the flow and

31、structure of an incident are focused. The flow and the handling are useful in determining whether an event is to be classified as an event, an incident, a security incident or a crisis. The flow also covers the critical first decisions that have to be made. This Recommendation provides an overview a

32、nd framework that gives guidance for planning incident organization and security incident handling. This Recommendation is generic in nature and does not identify or address requirements for specific networks. This Recommendation is intended to facilitate international developments regarding telecom

33、munication network security. Such developments would be facilitated if the requirements of this Recommendation could also be applied to the national Information and Communication Networks (ICN). To be able to succeed in incident handling and incident reporting, an understanding of how incidents are

34、detected, handled and resolved is necessary. By establishing a general structure for incidents (i.e., physical, administrative or organizational, and logical incidents) it is possible to obtain a general picture of the structure and flow of an incident. A uniform terminology is the base for a common

35、 understanding of words and terms. When reporting or handling an incident, the use of different taxonomies leads to misunderstanding. This may, in turn, result in an ICN security incident getting neither the proper attention, nor the prompt handling, that is needed in order to stop, contain and prev

36、ent the incident from recurring. This may lead to serious consequences for the affected organization (victim). This Recommendation describes the flow and the handling of an incident. The definition of an incident varies among professions, organizations and people. According to the general meaning of

37、 an incident, it may be anything from an erroneous backup, disruption of services, attack by a virus, to intrusion into computer systems. 1.2 Definitions ISO 17799 mentions incident, security incident and information security incident. Only the term “security incident“ is defined as a “security brea

38、ch, threat, weakness and malfunction that might have an impact on the security of organizational assets“. Nowhere are the terms “incident“ and “information security incident“ explained. In this Recommendation, it is assumed that an incident is less severe than a security incident and that an informa

39、tion security incident is a particular type of security incident. 2 ITU-T Rec. E.409 (05/2004) CatastrophCrisisee.g., big fireSecurity Incidente.g., trespassing, computerintrusionIncidente.g., availability problem in a networkEventsCrisis or catastrophe teamIncident response teamSecurity Incident Re

40、sponse TeamPermanent organi ationzHelp-Desk Support, etc.SeriousnessFigure 1/E.409 The pyramid of events Figure 1 shows the pyramid of events. At the bottom we find the event, followed by incident, security incident and at the top crisis and catastrophe. The closer to the top an event is, the more s

41、erious. In order to make use of a common and sound vocabulary regarding incident handling within the ICN area, this Recommendation defines the following terms: 1.2.1 event: An event is an observable occurrence which is not possible to (completely) predict or control. 1.2.2 incident: An event that mi

42、ght have led to an occurrence or an episode which is not serious. 1.2.3 security incident: A security incident is any adverse event whereby some aspect of security could be threatened. 1.2.4 Information and Communication Networks (ICN) security incident: Any real or suspected adverse event in relati

43、on to the security of ICN. This includes: Intrusion into ICN computer systems via the network; Occurrence of computer viruses; Probes for vulnerabilities via the network into a range of computer systems; PABX call leak-through; Any other undesired events arising from unauthorized internal or externa

44、l actions. 1.2.5 crisis: A crisis is a state caused by an event, or the knowledge of a forthcoming event, that may cause severe negative consequences. During a crisis, one may, in best cases, have the possibility of taking measures to prevent the crisis from becoming a catastrophe. When a catastroph

45、e occurs, a Business Continuency Plan (BCP) normally exists as well as a crisis management team to handle the situation. 1.3 Rationale It is recommended that telecommunication organizations creating (computer security) incident response teams, as the first step, declare their use of taxonomy in orde

46、r to avoid misunderstandings. Collaboration is much easier when using the same “language“. It is recommended that organizations use the term Incident and ICN Security Incident and define their own subdivisions according to the severity of the latter. In essence, an ICN security incident is any undes

47、ired, unauthorized event. This means that an ICN security incident includes computer intrusion, denial of service attack or a virus depending on the motivation, experiences and available ITU-T Rec. E.409 (05/2004) 3 knowledgeable resources in the organization. In organizations that have created an e

48、ffective virus fighting team, viruses may not be considered as ICN security incidents but rather as incidents. An example, or template, of such a subdivision could be as follows: Incidents Violating Internet Netiquette (Spamming, Abusive Content, etc.) Violating security policies Individual viruses

49、ICN Security Incidents Scans and probes Computer intrusions Computer sabotage and damage (availability attacks as bombing, DoS-attacks) Malicious software (viruses, Trojans, worms, etc.) Information theft and espionage Impersonation By using the same granularity and preciseness in terminology it is possible to gain experience in: guidance of the severity and scope; indication of the need for speed; effects of likely countermeasures; possible costs involved. 2 System description 2.1 Structure and flow By establishin