scope:

Scope, Purpose, and Application

In some telecommunications networks, management traffic is often transmitted on a separate network from that carrying the service provider's end-user traffic. In these networks, security threats to the management plane are completely isolated from any malicious activity on the end-user plane. The management plane is relatively easy to secure because access to this plane is restricted to known administrators, and traffic is restricted to known management activities. However, in some cases management traffic is combined on a single network with the service provider's end-user traffic. Combining traffic in this manner minimizes costs by requiring only a single integrated network infrastructure; however, many new security challenges are introduced. Threats in the end-user plane now become threats to the management and control planes. The management plane now becomes accessible to the multitude of end-users, and many types of malicious activities become possible. The purpose of this standard is to recommend minimum baseline security mechanisms to help mitigate security risks in the management of telecommunications networks.

To provide a complete end-to-end solution, all security measures (e.g., access control, authentication) should be applied to each type of network activity (i.e., management plane activity, control plane activity, and end user plane activity) for the network infrastructure, network services, and network applications. This standard focuses specifically on the security aspect of the management plane for network elements (NE) and management systems (MS), which are part of the network infrastructure. As such, the standard addresses only one aspect of an overall end-to-end security solution, but may be used as a starting point for subsequent standards addressing the security of "control" and "end user" planes, as appropriate.

The requirements in this standard are applicable to NEs and MSs to be deployed in the future. For NEs in the network that do not meet all the mandatory security requirements, the overall security requirements at the network architecture design should be supported. This standard addresses security for NE, MS, and element management system (EMS) equipment, and does not specifically address security for other equipment such as customer premise equipment (e.g., voice over Internet Protocol [IP] telephones) or independent test gear. For such other equipment, all mandatory requirements in this standard should be considered objective recommendations.

This standard has been used by the International Telecommunication Union - Telecommunications Sector (ITU-T) as the base to develop the M.3016.x series of Recommendations. ITU-T Recommendations M.3016.1, M.3016.2 and M.3016.3 specify the requirements, services, and mechanisms for the appropriate security of the management functions necessary to support the telecommunications infrastructure. Because different administrations and organizations require varying levels of security support, ITU-T Recs. M.3016.1, M.3016.2 and M.3016.3 do not specify whether a requirement/service/mechanism is mandatory or optional. ITU-T Rec. M.3016.4 defines a profile proforma template to assist administrations and other national/international organizations to specify the mandatory and optional support of the requirements as well as value ranges, values, etc. to help implement their security policies. This standard requires all implementers to list the security requirements supported in their implementations in terms of the requirements as enumerated by this standard. In addition, this standard suggests that for implementers with international interests, the ITU-T M.3016.x series of Recommendations may also be used to specify the security profiles of their implementations. If an implementer chooses to provide such a dual specification of their security implementation, then a mapping between the requirements as enumerated by this standard and those enumerated by the ITU-T M.3016.x series should also be provided. Note that if this "dual specification" process becomes widely adopted, then this standard may be updated in the future to include the preferred mapping algorithm in order to reduce the possibility of different mapping algorithms being used by different implementers.

Framework and Model

In the context of this standard, to secure something means to protect it (i.e., computers, networks, data, or other resources) from unauthorized access, use, or activity. Loss of data, denial of service (DoS), theft of service, and loss of customer confidence are only some of the results of security incidents. System and network administrators need to protect systems and their component elements from users and from attackers. Although security is multifaceted (spanning operations, physical, communications, processing, and personnel), of concern here are security problems resulting from weaknesses inherent in commonly employed configurations and technology. A threat consists of, but is not limited to, disclosure, unauthorized use, change, and denial of service.

These security threats may be minimized or mitigated within a network system or NE platform or application by inclusion of security services (as defined in ISO 7498-2:1989 Information Processing Systems-Open Systems Interconnection Basic Reference Model-Part 2: Security Architecture) to enforce the following:

- Identification and AUTHENTICATION;

- Authorization and ACCESS CONTROL Level;

- Data Integrity;

- Privacy and Confidentiality; and

- Nonrepudiation.

This standard addresses security for the management plane -- that is, security features to ensure that the network can be administered and managed in a secure manner. Some vulnerability may still exist, even after following the recommendations contained in this standard. The following risks are among those with the capability to compromise the management plane:

- Inappropriate actions by authorized users. These actions can be either malevolent or accidental.

- Security for the control plane (e.g., signaling, routing, naming, and discovery protocols) and the end-user plane.

- The effects of vulnerabilities in specific protocols.

- Malware (e.g., viruses, Trojan horses, worms, or other embedded code). Once malware successfully compromises any NE/MS, the malware may use the secure network communication links to transmit attacks to other NE/MS components. These attacks may continue until network managers detect the attack and take action to eliminate it.

This standard is concerned with the security of management traffic, especially when it traverses networks mixed with end-user traffic. Figure 1 illustrates a reference model that is used to specify network management security solutions. This model is used to examine logical communication paths within the entire network, and quantify which protocols are used for communications on each path. Using this model, threats and vulnerabilities can be examined for each path, and appropriate security mechanisms can be applied.

Multivendor NEs are shown at the bottom of the model in Figure 1. EMSs that provide specific management functions for the particular NE are illustrated above the NE. The network management system (NMS) itself is at the top of the model. The NMS provides overall management to the NE and EMS, and contains specific service and business management applications (e.g., configuration and billing systems). Remote and local operators are also shown in the model, and communication paths are shown with all other system elements.

The Security Reference Model (Figure 1) may also be useful in correlating telecommunications management network (TMN)-defined interfaces to the security model. The TMN is defined in International Telecommunication Union - Telecommunications Sector (ITU-T) Recommendation M.3010, Principles for a telecommunications management network. It is defined as an architecture for management, including planning, provisioning, installation, maintenance, operations, and administration of telecommunications equipment, networks, and services.

In the TMN standard, against which service providers have indicated they will standardize, it is identified that multiple network infrastructures and multiple TMNs may exist. In fact, the management of NEs by their associated MSs in the typical service provider environment may traverse numerous data communications networks (DCN). This management traffic may need to negotiate several access control mechanisms (e.g., firewall devices or router access lists, and/or network connections and interconnections) in order to get to the NE in question. NEs must traverse many of the same networks and interconnections for return traffic. As such, vendors should know and understand the possible latency issues and work towards delivering solutions to address those issues.

Applicability of this standard to the TMN

This standard applies to the entirety of the TMN covering both circuit-based NEs and packet-based NEs. Circuit-based NEs provide multiple logical interfaces between switches, transmission elements, signaling elements, and other special-purpose elements that are designed and developed to support traditional telephony services. The packet-based NE model has migrated from the centralized system where all functions were hosted on one platform to a more distributed system where functions may be hosted by multiple platforms coupled together to form a complete system. These functions can be service or operations related. This standard provides a security framework to protect all of the facilities of the NE/MS that are exposed to various threats and risks. This includes platforms, visible interfaces, and associated functions, applications, and services. To provide equal protection to all types of NE/MS, the total overall system security features should be the same for all types of NE/MS. However, depending on the architecture of the resident, distributed features, and the available processing capabilities, the implementation scheme of the security features in NE/MS may be different in its details.

Some NE/MS will have the capacity to incorporate security features within themselves. They can fully implement all of the mandatory security requirements in this standard. Other NE/MS will not have the capacity to incorporate all of the mandatory security features defined in this standard within them. It may be unrealistic to ask for all security features to be embedded within the NE/MS operating system (OS) or application layers of these devices. For these types of devices that exist in or are placed into a network, their security properties should be augmented so that the system meets the requirements of this standard. As an example, if a MS cannot provide STRONG ENCRYPTION for MANAGEMENT ACTIONS over a TRUSTED PATH, then an auxiliary device may be placed in the network path so that MANAGEMENT COMMUNICATIONS passing through this device may be performed over an encrypted SESSION. As another example, if an NE cannot directly enforce COMPLEX PASSWORDS, then it may utilize an ACCESS CONTROL server (ACS) that can.