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
