NFM-P system security

Platform security

The RHEL OS is common to all NSP components, including the NFM-P. The OS is protected by firewalls and stringent internal security measures that restrict access to files and functions. The NFM-P supports platform-wide mechanisms such as SELinux, which records RHEL user actions, and HTTPS Strict-Transport-Security (HSTS), which restricts client browser access. NE management communication can be secured using protocols such as SNMPv3, as well as the strong security associated with the Federal Information Processing Standards (FIPS).

See the NSP Security Hardening Guide for more information about NSP platform security.

Communication security

The NFM-P employs strict security at the session and other communication layers. Interfaces between a main server and other system components are secured using Transport Layer Security, or TLS.

Communication with a main database is secured using Oracle Network Data Encryption.

A GUI, application, or OSS client must provide user credentials for access to the NFM-P. Session credentials and messages are protected using mechanisms and protocols that include the following:

• HTTPS, as the application-layer transport for clients

• SSH, SCP, and SNMPv3 with USM or VACM, at the application layer for communication between a main server and the managed network

• NAT, at the network layer, between the following:

  • main server and single-user GUI client or client delegate server

  • main or auxiliary server and OSS client

  • main or auxiliary server and managed network

• IP validation, at the network layer, between the main or other server components and each main database

The following figure shows the NFM-P components and the security mechanisms.

Figure 6-2: NFM-P security mechanisms

NFM-P session management

An NFM-P operator can configure authentication, accounting, and administrative (AAA) functions using the local NFM-P security mechanisms, a third-party server, or both.

• Local NFM-P authentication is performed using a local database of users and a local security scheme.

• Supported remote authentication servers are RADIUS, TACACS+, LDAP and LDAP-S, and CSA, which have separate user lists and administration processes.

NFM-P user accounts consist of a user name, password, and an associated user group, scope of command, and span of control over network objects. User groups define user authorization levels, and control the level of access to objects such as equipment, customers, services, and alarms. An NFM-P administrator can limit the type of user access per managed NE; for example, allowing FTP access but denying console or SNMP access.

Client sessions

Client sessions use the following authentication mechanisms.

• A GUI client EJB session is authenticated using the client username and password.

• An OSS client session is authenticated using cached information from an authorization server.

• A JMS session is authenticated using the client username and password.

Database sessions

A main database is accessible through a connection that is secured by a user name and password. After each database update in response to a GUI or OSS client request, the client activity log records the request information, which includes the user name.

Secure communication between a main server and main database is available using IP validation, which is typically configured on a main database station during installation or upgrade.

Managed NE sessions

A main or auxiliary server opens CLI, FTP, SFTP and SCP sessions on managed NEs. A managed NE uses a local security database, or a third-party service such as RADIUS or TACACS+, to perform AAA functions.

SNMPv3 message authentication and authorization are handled by the USM and VACM mechanisms, which define the user authorization permissions. Older SNMP versions are authenticated using community strings. Each SNMP message is individually authenticated.

Network transport security

Transport-layer security is available to the network protocols that carry messages between NFM-P components.

Main server and clients

Communication between a main server and clients is performed using messaging such as the following.

• XML API clients use HTTP or HTTPS to send XML/SOAP messages, and receive notifications using JMS, which can be secured using TLS.

• REST API clients use HTTPS.

• GUI clients use the EJB interface, which can be secured using TLS.

Servers and managed NEs

When SNMPv3 is used, an authentication key using current algorithms and ciphers is included in each message and checked against the shared encryption key. SSH provides the security for a CLI session between a GUI client and a managed NE.

RSA encryption is available for communication between auxiliary servers and managed NEs; contact customer support for information.

Firewall support

The NFM-P supports firewall deployment on all server interfaces; for example, between a main server and the auxiliary servers, GUI, and OSS clients, and between a main or auxiliary server and the managed network. See the NSP Planning Guide for firewall and reserved TCP port information.