ANSI ATIS 1000029-2008 Security Requirements for NGN.pdf

《ANSI ATIS 1000029-2008 Security Requirements for NGN.pdf》由会员分享，可在线阅读，更多相关《ANSI ATIS 1000029-2008 Security Requirements for NGN.pdf（41页珍藏版）》请在麦多课文档分享上搜索。

1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000029.2008(R2013) Security Requirements for NGN As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pressing business priorities. Through ATIS committ

2、ees and forums, nearly 200 companies address cloud services, device solutions, emergency services, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a fast-track development lifecycle from design and inn

3、ovation through solutions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American Organizational Partner for the 3rd Generation Partne

4、rship Project (3GPP), a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit. AMERICAN NATIONAL STA

5、NDARD Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substantial agreem

6、ent has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made towards their resolution. The use of Am

7、erican National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Stan

8、dards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards Institute

9、. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the American National Standards Institute require that ac

10、tion be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute. Notice of Disclaimer NGN services and capabilities (e.g., voice, vide

11、o and data services); End user communication and information (e.g., private information). Adherence to these requirements will provide network-based security of end user communications across multiple-network administrative domains. Security of customer assets and information in the customer domain

12、(e.g., user network), and the use of peer-to-peer application capabilities on customer equipment are not within the scope of this standard. The requirements specified in this standard are applicable to an NGN, including User-to-Network Interfaces (UNIs), Network-to-Network Interfaces (NNIs), and App

13、lication-to-Network Interfaces (ANIs) in a multi-network environment. NGN providers will be deploying “network elements” that support the functional entities described in ATIS-1000018 1 and ITU-T Recommendation Y.2012 8. The bundling of these functional entities to a given network element will vary,

14、 depending on the vendor. Therefore, this standard will not attempt to show a strict and fixed bundling of logical functional entities and physical network elements. The requirements in this standard should be treated as a minimum set of requirements for NGN security and should not be considered to

15、be exhaustive. Therefore, an NGN provider may need to take additional measures beyond those specified in this standard. In addition, the requirements in this document cover some of the technical aspects of what is generally known as “Identity Management (IdM).” A working definition of IdM is “manage

16、ment by NGN providers of trusted attributes of an entity such as: a subscriber, a device or a provider”. This is not intended to indicate positive validation of the identity of a person. Administrations may require NGN providers to take into account national regulatory and national policy requiremen

17、ts in implementing this standard. Note: In this document, use of the term “NGN provider” includes all types of providers in an NGN environment such as service providers, network providers, access providers and transport providers. ATIS-1000029.2008 2 1.1 General security principles ITU-T Recommendat

18、ion X.805, Security architecture for systems providing end-to-end Communications 6 and ATIS-1000007, Generic Signaling and Control Plane Security for Evolving Networks 1 defines the following security dimensions. Access control Authentication Non-repudiation Data confidentiality Communication securi

19、ty Data integrity Availability Privacy It also identifies the security threats shown in Figure 1. X.805_F3AccesscontrolInfrastructure securityServices securityEnd-user planeControl planeManagement planeTHREATSVULNERABILITIES8 Security dimensionsATTACKSData confidentialityCommunicationsecurityData in

20、tegrityAvailabilityPrivacyAuthenticationNon-repudiation DestructionDisclosureCorruptionRemovalInterruptionSecurity layersApplications securityFigure 1 Security architecture of X.805 (Figure 3/X.805) These security dimensions and security threats stated above are considered as the basis of this stand

21、ard. This standard does not further define or distinguish the use of the X.805 security layers (Applications, Services, or Infrastructure) and compliance with this standard does not require such a distinction. This standard does make reference to a distinction between Management, Control, and User p

22、lane traffic, but cautions the reader that the utilization of that classification varies depending on the layer in a protocol stack that is under consideration. Therefore, additional standards will need to be referenced to determine compliance with such distinctions. This standard provides recommend

23、ations concerning application of the Security Dimensions, but does not infer completeness for use as a security assessment for NGN. ATIS-1000029.2008 3 1.2 Assumptions This standard is based on the following assumptions: 1. The bundling of functional entities defined in ATIS-1000018 1 and ITU-T Reco

24、mmendation Y.2012 8 to a given network element will vary, depending on the vendor. 2. Each NGN provider has specific responsibilities within its domain for security. Examples include implementing applicable security services and practices to a) to protect itself, b) to assure end-to-end security is

25、not compromised within its network, and c) to assure high availability of NGN communications. 3. Each network domain will establish and enforce policies for Service level Agreements (SLAs) to assure the security of its domain and the security of its network interconnections. It is assumed that the S

26、LAs would specify security services, mechanisms and practices to be implemented to protect the interconnected networks and the communications (signaling/control traffic, bearer traffic and management traffic) across UNIs, ANIs and NNIs. Policy enforcement is outside the scope of this document. 4. Th

27、is standard addresses network-based security, for a layered architecture, consisting of perimeter security to trusted domains, physical security of provider equipment, and the potential use of encryption. 1.3 Document overview This standard is organized as follows: Clause 2 (References) This section

28、 provides normative references. Clause 3 (Definitions and abbreviations) This clause provides definitions and abbreviations used in this Recommendation. Clause 4 (Security threats and risks) This clause highlights security threats and risks assumed for the NGN environment. Assumed security threats a

29、nd risks are used as guidance to develop requirements for security and to identify security capabilities and procedures to be supported. Clause 5 (Security trust model) This clause describes a trust model for NGN security. The trust model can be used to develop trust relations for UNI, ANI and NNI c

30、onnectivity and design of security architecture. Clause 6 (Security architecture) This clause describes the relationship between the functional NGN architecture defined in ATIS-100018 1 and ITU-T Recommendation Y.2012 8 and composite security architectures. Clause 7 (Objectives and requirements) Thi

31、s clause describes security objectives and general requirements for NGNs to be used as the basis to define security requirements for NGNs. Clause 8 (Specific security requirements) This clause provides specific security requirements to meet the objectives given in clause 7. Bibliography ATIS-1000029

32、.2008 4 This standard is defined to provide a basis for NGN security. Various companion standards for specific security areas, e.g., authenticaition and authorization, certificate management, identity management, among others, are to be provided in the future. 2 References The following standards co

33、ntain provisions which, through reference in this text, constitute provisions of this American National Standard. At the time of publication, the edition indicated was valid. All standards are subject to revision, and the parties to agreements based on this American National Standard are encouraged

34、to investigate the possibility of applying the most recent edition of the standard indicated below. 1 ATIS-1000018, NGN Architecture.12 ATIS-1000007.2006(R2011), Generic Signaling and Control Plane Security for Evolving Networks.13 ATIS-1000010.2006(R2011), Security for Next Generation Networks - An

35、 End User.14 ITU-T Recommendation Y.2701, Security Requirements for NGN Release 1.25 ITU-T Recommendation X.800 (1991), Security architecture for Open Systems Interconnection for CCITT applications.26 ITU-T Recommendation X.805 (2003), Security architecture for systems providing end-to-end Communica

36、tions.27 ITU-T Recommendation Y.2201, NGN release 1 requirements.28 ITU-T Recommendation Y.2012, Functional requirements and architecture of the NGN.29 ITU-T Recommendation M.3016.0 (2005), Security for the management plane: Overview.210 ITU-T Recommendation M.3016.1 (2005), Security for the managem

37、ent plane: Security requirements.211 ATIS-0300276.2008,Operations, Administration, Maintenance, and Provisioning Security Requirements for the Public Telecommunications Network: A Baseline of Security Security Requirements for the Management Plane.112 ATIS-1000019.2007, Network to Network (NNI) Stan

38、dard for Signaling and Control Security for Evolving VoP Multimedia Networks.113 ATIS-1000012.2006(R2011), Signaling Systems No. ATIS-1000029.2008 8 Break-in/Device takeover resulting in loss of control of the device, anomalies and errors detected by configuration audits; Destruction of information

39、and/or other resources; Corruption or modification of information; Theft, removal or loss of information and/or other resources; Disclosure of information; Interruption of services and denial of services. Further, it is clear that NGNs will be operating in an environment different from the PSTN envi

40、ronment and may therefore be exposed to different types of threats and attacks from within or externally. NGNs will have direct or indirect connectivity to un-trusted and trusted networks and terminal equipment, and therefore will be exposed to security risks and threats associated with connectivity

41、 to un-secure networks and customer premise equipment. For example, a providers NGN may have direct or indirect (i.e., through another network) connectivity to the following as shown in Figure 2: Other service providers, and their applications; Other NGNs; Other IP-based networks; Public Switched Te

42、lephone Network (PSTN); Corporate networks; User networks; Terminal Equipment. Other NGN transport domains ATIS-1000029.2008 9 TransportNext Generation Network Application ServersSoftswitchCSCFService StratumOther NGNsOther IP-based NetworksOtherService ProvidersCorporate networksUsernetworksTermina

43、l EquipmentANI NNI UNI Connectivity to trusted and un-trusted networksPSTNConnectivity to un-trusted customer equipmentFigure 2 - Connectivity to networks and users In the evolving environment, security across multiple network provider domains relies on the aggregation of what all providers elect to

44、 do for securing their networks. Unauthorized network access into one providers network can easily lead to exploitation of an interconnected network and its associated services. This is an example of the exploitation of the weakest link that can threaten a provider networks integrity and service con

45、tinuity via various types of attacks. Each NGN provider is responsible for security within its domain. Each NGN provider is responsible for designing and implementing security solutions using network specific policy for trust relations (clause 5), to meet its own network-specific needs and to suppor

46、t global end-to-end security objectives across multiple network provider domains. 5 Security trust model This clause defines the NGN security trust model. The NGN functional reference architecture defines Functional Entities (FEs). However, since network security aspects depend heavily on the way th

47、at FEs are bundled together, the NGN security architecture is based on physical Network Elements (NEs), i.e., tangible boxes that contain one or more FEs. The way these FEs are bundled into NEs will vary, depending on the vendor. 5.1 Single network trust model This sub-clause defines three security

48、zones; 1. Trusted, 2. Trusted but vulnerable, 3. Un-trusted, ATIS-1000029.2008 10 These security zones are dependent on operational control, location, and connectivity to other device/network elements. The three zones are illustrated in the security trust model shown in Figure 3. TrustedZoneTrusted

49、butVulnerableZoneUntrusted ZoneNetwork Elements controlled bythe NGN providerNetwork Elements not always controlledby the NGN providerNGNnetworkElementsNetworkBorderElements(NBE)TE-BETETEProvider-controlledEquipment TE-BETETEFigure 3 - Security trust model An “internally trusted network security zone” or “trusted zone” in short, is a zone where a NGN providers network elements and systems reside and never communicate directly with customer equipment or other do