NSP Network Services Platform Release 20.9 System ...

NSPNetwork Services PlatformRelease 20.9

System Architecture Guide

3HE-16053-AAAC-TQZZA

Issue 1

September 2020

Legal notice

Nokia is a registered trademark of Nokia Corporation. Other products and company names mentioned herein may be trademarks or

tradenames of their respective owners.

The information presented is subject to change without notice. No responsibility is assumed for inaccuracies contained herein.

© 2020 Nokia.

NSP


Release 20.9September 2020

2 Issue 1

Contents

About this document............................................................................................................................................4

1 About the NSP ................................................................................................................................................5

1.1 NSP product description .....................................................................................................................5

1.2 NSP system components....................................................................................................................6

1.3 Network management functions..........................................................................................................9

2 System structure ..........................................................................................................................................11

2.1 Core NSP system elements ..............................................................................................................11

2.2 Central management functions .........................................................................................................12

3 Component communication........................................................................................................................15

3.1 NSP inter-component and internal communication...........................................................................15

4 Security .........................................................................................................................................................17

4.1 Overview ...........................................................................................................................................17

5 NSP system redundancy .............................................................................................................................19

5.1 NSP redundancy models ..................................................................................................................19

5.2 NSP Role Manager ...........................................................................................................................20

5.3 NSP redundancy mechanisms and failure scenarios........................................................................21

A Standards compliance.................................................................................................................................29

A.1 Supported standards and interfaces .................................................................................................29

B NSP data privacy summary .........................................................................................................................31

B.1 NSP network and user data privacy..................................................................................................31

C NSP RHEL OS compliance with CIS benchmarks.....................................................................................37

C.1 RHEL CIS benchmarks and NSP compliance...................................................................................37

Contents NSP

Release 20.9September 2020Issue 1 33HE-16053-AAAC-TQZZA

About this document

Purpose

The NSP System Architecture Guide describes the Network Services Platform architecture and

interoperation with other systems from a high-level perspective. The audience is a technology

officer, network planner, or system administrator who requires a broad technical understanding of

the NSP system structure and design methodology.

Scope

The guide scope is limited to a description of the integral elements that are common to NSP

components. For information about the architecture of a specific NSP component, or a product or

appliance that integrates with the NSP, see the component, product, or appliance documentation.

Related documentation

• NSP System Administrator Guide

• NSP Deployment and Installation Guide

• NSP Planning Guide

Document support

Customer documentation and product support URLs:

• Documentation Center

• Technical support

How to comment

Documentation feedback

About this document NSP



4 Issue 1

http://documentation.nokia.com

https://customer.nokia.com/support/s

mailto:[email protected]

1 About the NSP

1.1 NSP product description

1.1.1 The NSP system

The Network Services Platform, or NSP, is a network management system that provides service

management functions within and across network domains. The NSP provides interfaces for

performing multi-layer service preconfiguration, rollout, and activation, and can manage services

that employ multiple technologies and span the IP/MPLS, optical, and wireless domains.

The NSP also manages the physical and virtual network infrastructure, including equipment from

third-party vendors.

The NSP can integrate IP/MPLS and optical management platforms to:

• accelerate the creation and rollout of on-demand IP/optical network services

• enable real-time service optimization and flow steering

• extend assurance capabilities and automates assurance functions

1.1.2 Design ideology

The NSP incorporates design considerations that include:

• open standards that promote interoperation with third-party management systems

• flexible internal architecture to accommodate new functions

• deployment flexibility for adaptation to changing network management scope or complexity

• centralized, proprietary nspOS resource base for system components

• centralized web services and single sign-on, or SSO, access to NSP applications

• distributed processing for efficiency and horizontal scalability

• redundant component deployment and other fault-tolerance mechanisms

• stringent security between components

• secure local and remote client access

1.1.3 NSP Launchpad

The browser-based NSP Launchpad is the graphical operator interface that provides access to the

NSP applications. You can also use the Launchpad to open other applications and traditional

management interfaces, gain access to user documentation, and perform basic system

administration. Some NSP applications support the cross-launch of other applications.

About the NSPNSP product description

NSP


1.2 NSP system components

1.2.1 Common nspOS resource base

Each NSP component includes the nspOS, as does the NFM-T product. In a shared-mode NSP

deployment, the nspOS runs on an NSP cluster. In an NSP deployment that does not include an

NSP cluster, a server in a component system such as the NFM-P or NFM-T hosts the nspOS.

Only one nspOS instance is active at any time. For example, in a redundant NSP deployment that

includes NSP clusters, the active nspOS instance runs on the primary NSP cluster. One exception

is a split-brain scenario, which is described in 5.3.5 “NSP cluster communication failure” (p. 24).

When an independent system is converted to a shared-mode deployment, the nspOS instance in

the independent system remains, but is no longer active; instead, the active nspOS instance runs

on the standalone or primary NSP cluster.

The nspOS services and functions include the following:

• Login—grants SSO access to all NSP applications, GUI clients, and other resources on the

NSP Launchpad

• NSP Launchpad—entry point for all NSP applications

• Central Authentication Server, or CAS—authenticates user login attempts

• Session Manager—tracks and manages SSO sessions

• REST API gateway—acquires NSP REST API tokens and locates specific NSP APIs

The nspOS also contains a service registry, distributed streaming platform, and graph database.

1.2.2 NSP components

The following table lists main NSP components and describes the terminology around the

components and related concepts. In Releases earlier than 20.6, some components had different

names, and were called modules. The table includes the former component name, if applicable.

Note: “NSD and NRC” is a former term to describe a combination of NSP functions that are

now distributed among IP resource control, Cross domain resource control, and other NSP

components and functions.

Table 1-1 NSP component terminology

Component Expanded name Former name Functional domains or description

Cross domain

resource control

Cross-domain Resource

Control

NRC-X (Network

Resource Controller -

Cross-domain)

Cross Domain Coordinator application,

which provides:

• IP/optical traffic correlation

• Cross-domain link creation and

discovery

About the NSPNSP system components

NSP



6 Issue 1

Table 1-1 NSP component terminology (continued)

Component Expanded name Former name Functional domains or description

IP resource

control

IP Resource Control NRC-P (Network

Resource Controller -

Packet)

IP/MPLS Optimization application

• IP/MPLS network optimization

• IP/MPLS path computation

• Flow steering based on statistics,

analytics, and operator action

NFM-P Network Functions

Manager - Packet

— NFM-P application

• Classic IP management of NEs

• IP/MPLS network infrastructure

management

• IP/MPLS network and service

assurance

• Traditional L2 and L3 service

management

MDM Model-driven mediation — A sub-component of the NSP cluster

responsible for model-driven IP

management to multi-vendor NEs and

model-driven SR OS NEs. Also

supports third-party controllers.

NSP deployment

with classic and

model-driven IP

management

— WAN SDN (Wide-area

Network Software Defined

Networking) deployment

NSP deployment that includes Classic

IP (i.e. NFM-P) and MDM management

NSP host server Network Services Platform

host server

NSP server A discrete RHEL-based physical or

virtual processing entity that hosts an

NSP component; for example, IP

resource control or Cross domain

resource control.

“NSP server” remains in use to

describe the NSP server processes as

one abstract entity that runs on an

NSP host server and communicates

with other NSP components and

external systems.

NSP cluster Network Services Platform

cluster

— NSP component comprised of one or

more stations that host the nspOS

instance and optional functions such

as the MDM and WFM

A shared-mode NSP deployment must

include an NSP cluster.

Simulation tool — NRC-P Sim A traffic-engineering tool used by

network engineers to design highly

optimized traffic flows

1.2.3 Other NSP system components

An NSP system can also include the following.


NSP


NFM-T

An NSP deployment that requires optical management functions must include the NFM-T product,

which is an evolution of the former 1350 OMS product. The NFM-T provides end-to-end optical

management functions that include service provisioning over multi-technology optical transport

networks such as SDH/SONET, carrier Ethernet, WDM, ROADM, OTN, and packet. Browser-based

fault management applications reduce the time and cost of network and service assurance

operations, and an API enables OSS integration.

For more information about the NFM-T, see the NFM-T Getting Started Guide.

VSR-NRC

The Nokia Virtual Service Router - Network Resources Controller (VSR-NRC) acts in a Virtual

Network Function (VNF) capacity to perform topology discovery. The VSR-NRC is based on the

SROS software, and implements the southbound protocols of the IP/MPLS Optimization

application, which consist of the Path Computation Element (PCE) function, with PCEP, BGP-LS

and IGP protocols, and the OpenFlow Controller (OFC).

The VSR-NRC is a virtual SR OS instance that uses the same software image as the vSIM of the

same SROS release number; the VSR-NRC license enables additional functions for interaction with

the NSP; the software run only in a Linux KVM environment.

The VSR-NRC instance has a physical interface to the network and collects topology information

and signaled path computation requests from head-end routers. The VSR-NRC is connected to the

network by way of a PE router.

For platform requirements and installation instructions, see the Virtualized 7750 SR and 7950 XRS

Simulator (vSIM) Installation and Setup Guide.

NSP Flow Collectors and Flow Collector Controllers

An NSP Flow Collector is an optional, scalable component that collects AA Cflowd or System

Cflowd statistics directly from NEs and forwards the statistics records to one or more remote target

servers, or to an NFM-P database, after which they are available for processing by third-party tools

or by applications such as NSP Analytics.

An NSP Flow Collector Controller is required in any deployment that includes one or more NSP

Flow Collectors. The Flow Collector Controller extracts the network data model from the NFM-P and

distributes the data model to each Flow Collector, which uses the data model as a statistics-

collection framework. The controller receives NFM-P JMS notifications about updates to the objects

in the data model, and directs Flow Collector activity by distributing the messages to the

appropriate Flow Collectors.

Like other NSP components, NSP Flow Collectors and NSP Flow Collector Controllers support

redundant deployment. You can deploy two NSP Flow Collector Controllers that each manage a set

of NSP Flow Collectors.

Note: The NSP Flow Collector Controller that initializes first assumes the active role.

For a small-scale deployment, you can collocate an NSP Flow Collector Controller and an NSP

Flow Collector on one station. A small-scale deployment has a maximum of two stations, and

supports the following:


NSP



8 Issue 1

• standalone—one station that hosts a Flow Collector Controller and Flow Collector, and a second

station that hosts only a Flow Collector

• redundant—two stations that each host a Flow Collector Controller and Flow Collector

In a redundant NFM-P system, when an NSP Flow Collector Controller cannot reach the primary

NFM-P main server, the Flow Collector Controller tries to reach the standby main server.

See the NSP NFM-P Administrator Guide for information about NFM-P redundancy and other fault-

tolerance mechanisms.

NSP analytics servers

An NSP analytics server creates on-demand and scheduled reports about various network

conditions and trends for display in the NSP Analytics application. An analytics server generates the

reports using business intelligence software to analyze raw and aggregated NE statistics data

collected by the NFM-P.

Like other NSP components, NSP analytics servers support redundant deployment. You can deploy

multiple redundant analytics servers in an active/active configuration that eliminates a single point

of failure in the event that an analytics server fails. Deploying multiple analytics servers also allows

load balancing of client requests among the servers, and other fault-tolerance mechanisms.

See Chapter 5, “NSP system redundancy” for more information about redundancy and other fault-

tolerance mechanisms.

1.3 Network management functions

1.3.1 Overview

The NSP provides a comprehensive suite of browser-based applications for various network

management functions.

1.3.2 Service deployment and assurance

The NSP applications enable dynamic, rapid customer service rollout and validation. Each service

can be monitored to provide performance, usage, and fault information. Applications such as

Service Supervision, Fault Management, Network Supervision, and Wireless Supervision provide

information to assist in the timely apprehension, troubleshooting, root-cause analysis, and

correction of network and service issues.

1.3.3 Traffic optimization

Applications such as Traffic Steering Controller and IP/MPLS Optimization automate traffic

management by controlling and steering traffic flows as specified by a network operator.

1.3.4 Performance KPI monitoring and reporting

The NSP monitors network KPIs for immediate and trend-based reporting by NSP applications. The

reporting agents include the NSP Telemetry Monitor application, which receives near-real-time NE

KPIs, and NSP Analytics, which uses raw and aggregated flow statistics for long-term reporting to

identify trends and potential capacity issues.

About the NSPNetwork management functions

NSP


1.3.5 Equipment inventory management

The NSP uses information from systems such as the NFM-P, which maintains a dynamically

updated network equipment data store, for NSP applications such as Inventory Management.

An NSP system that includes the MDM enables the Device Administrator and Modeled Device

Configurator NSP applications for managing a network equipment inventory using model-driven

mediation.

1.3.6 Administrative and monitoring functions

Applications such as the NSP Workflow Manager, Policy Management, and Group Manager simplify

network administration. The NSP Service Navigator, Wireless NE Views, and Subscriber Manager

provide real-time views of network and service objects.

About the NSPNetwork management functions

NSP



10 Issue 1

2 System structure

2.1 Core NSP system elements

2.1.1 Description

The modular NSP architecture is readily adaptable to changing management needs, and simplifies

the transition from a 5620 SAM or 1350 OMS system. The architecture allows for network growth

and the addition of network functions.

The following figure shows a high-level view of the core NSP functions as a layered architecture

model.

System structureCore NSP system elements

NSP


2.2 Central management functions

2.2.1 Network data management and correlation

The NSP uses a Neo4j graph database to identify relevant connections between network events

and operator actions in order to maintain awareness of network conditions. Neo4j is the engine

behind NSP assurance applications such as Fault Management.

The NSP PostgreSQL database adds intelligent integration and interpretation functions to identify

complex network data relationships, and provides input to NSP applications for functions such as

root-cause analysis.

Figure 2-1 Core NSP functions, layered view

FAULTMANAGEMENT

SAM-O

NETWORK& SERVICESUPERVISION

ANALYTICS &REPORTING

SERVICEPROVISIONING

RESOURCECONTROL

OPTICALTRANSPORT

APPLICATION LAYER

MODELEDDEVICECONFIGURATOR

DEVICEADMINISTRATOR

COMMONMODELS

DATAPERSISTENCE

MESSAGING& LOGGING

REGISTRY SSO & USERMANAGEMENT

LICENSEMANAGEMENT

nspOS

TELEMETRY

NFM-P

IPRCNFM-T

COMMON

IP/MPLS BGP/IPCONTROL

BGP LS/CEPCONTROL

OPTICAL

NETWORK MEDIATION LAYER

APIs

REST RESTconf OMS-NBISAM-O

MDM

26793

System structureCentral management functions

NSP



12 Issue 1

2.2.2 Network state synchronization and event notification

The NSP uses the Kafka messaging subsystem, a subscription-based distributed streaming

platform, to synchronize network and operational information among NSP components, and to send

network event notifications to OSS consumers that subscribe to NSP Kafka topics.

2.2.3 NSP REST API

The NSP REST API is an abstracted interface for application developers can use to provision and

monitor network objects, and to subscribe to real-time network event notifications. The REST API

supports service assurance, and IP/MPLS and optical network management functions.

2.2.4 ZooKeeper registration service

The NSP ZooKeeper registration service maintains a repository of information about each NSP

component, and controls access to the active nspOS instance through which each component

gains access to the common NSP resource base of platform services.


NSP



NSP



14 Issue 1

3 Component communication

3.1 NSP inter-component and internal communication

3.1.1 Inter-component NSP communication

An NSP system employs various mechanisms and protocols for inter-component communication

that are beyond the scope of system deployment. The material in this chapter focuses mainly on the

deployment and initial configuration of NSP system security.

Note: Communication between NSP components is performed using IPv4 only; IPv6

communication is not supported.

NFM-P, NFM-T, and other communication with the NSP cluster is secured using TLS. Internal

NFM-P or NFM-T system communication is also secured using TLS.

Note: The NSP uses TLS 1.2; TLS 2.0 is not supported; the NFM-P supports TLS 2.0. In a

shared-mode deployment, the TLS versions of all components must match.

See the NSP Deployment and Installation Guide for information about deploying TLS in an NSP

system.

For information about NFM-P TLS deployment, see the NSP NFM-P Installation and Upgrade

Guide.

Communication between the NSP and the NFM-T is performed using REST over HTTPS. For

information about NFM-T TLS deployment, see the NFM-T product documentation.

3.1.2 Internal NSP communication

Transactional communication involving nspOS subsystems such as the ZooKeeper registry, Kafka

notification system, and PostgreSQL database can also be secured using TLS in a Release 19.6 or

later NSP system. TLS for nspOS is disabled by default for compatibility with system components at

earlier releases.

Internal NSP communication is TLS-secured using an internally generated certificate signed by an

internal CA. The use of an internal CA rather than a publicly trusted CA prevents intruder access to

internal functions through the use of any other certificate.

Note: In order to enable nspOS security, all NSP components and integrated products must

be at Release 19.6 or later.

Note: If all components of an NSP system are at Release 19.6 or later, enabling nspOS

security is strongly recommended.

Note: Only unsecured connections are supported between NFM-T and ZooKeeper/Kafka.

See NSP Deployment and Installation Guide for information about enabling nspOS security.

Component communicationNSP inter-component and internal communication

NSP


3.1.3 NFM-P bandwidth requirement

The bandwidth requirement between the NFM-P and the NSP depends on the number of NEs,

LSPs, and services in the NFM-P network, as well as the frequency of NE updates that are pushed

to other components.

Optimum performance during data resynchronization with the NFM-P is attained when 50 Mbps of

bandwidth is available. Service provisioning operations typically require less bandwidth; 25 Mbps or

greater is recommended.

Network latency affects how long it takes to resynchronize a large amount of data; It is

recommended that the latency between components does not exceed 100 ms.

3.1.4 NFM-T bandwidth requirement

The bandwidth requirement between the NFM-T and the NSP depends on the number of optical

devices and services in the NFM-T network.

A minimum of 10 Mbps of bandwidth is recommended between the NFM-T and the NSP. High

round-trip network latency may affect GUI performance, and must not exceed 100 ms.

Component communicationNSP inter-component and internal communication

NSP



16 Issue 1

4 Security

4.1 Overview

4.1.1 TLS

NSP interfaces are secured using Transport Layer Security, or TLS, which is implemented using an

NSP PKI server or customer-provided certificates.

Internal NSP services and processes are also secured using TLS. The internal implementation

provides additional security by using certificates generated by an internal root CA that is

inaccessible to external parties.

Session credentials and messages are protected using mechanisms and protocols that include the

following:

• HTTPS, as the application-layer transport for API clients

• SNMPv3, for secure SNMP communication with the managed network

• NAT, at the network layer, between system components

4.1.2 Session management

Effective session management requires authentication, authorization, and accounting, or AAA. For

greater security, the NSP does not maintain a local user database; only external user authentication

is supported.

In order for a user to gain NSP access, an authentication source such as LDAP, RADIUS,

TACACS+, or the NFM-P is required; local NSP authentication is not supported.

The NSP User Manager application provides user session management, user access control, and

user activity-logging functions.

See the NSP System Administrator Guide for more information about NSP user authentication and

management.

4.1.3 Network transport security

TLS is available for securing to the network protocols that carry messages between NSP

components.

4.1.4 Firewall support

The NSP supports firewall deployment on all NSP host server interfaces, as described in the NSP

Planning Guide. Firewall support among elements of individual component systems may vary. A

system such as the NFM-P or NFM-T may have firewall restrictions on specific interfaces between

system elements. See the component Planning Guide for information.

SecurityOverview

NSP


4.1.5 Standards compliance

The NSP incorporates industry standards and open-standard interfaces that allow system

interoperation with other network monitoring and management systems.

Appendix A, “Standards compliance” lists the industry standards and open-standard interfaces.

4.1.6 NSP data privacy

The NSP protects the network and user data that it collects or processes.

Appendix B, “NSP data privacy summary” describes the mechanisms that the NSP uses for private

data collection, storage, security, and retention.

4.1.7 OS hardening

The RHEL OS on each NSP component is hardened in accordance with Center for Internet

Security, or CIS, security benchmarks. Appendix C, “NSP RHEL OS compliance with CIS

benchmarks” describes the NSP compliance with each benchmark for the RHEL OS.

SecurityOverview

NSP



18 Issue 1

5 NSP system redundancy

5.1 NSP redundancy models

5.1.1 Description

Systems such as the NSP, NFM-P, and NFM-T support a 1+1, or warm standby, redundancy model

that consists of active and warm standby components. For example, the NFM-P has main server,

main database, and optional auxiliary components that perform additional functions. Each main or

auxiliary component supports redundancy. All active components require low network latency, so

ideally are geographically collocated.

Disaster recovery

For NSP disaster recovery, or DR, you can use the NSP 1+1 redundancy model in two

geographically separate locations. Only one system is active at a time; the active system hosts all

NSP applications and processes all client requests. The system at the other location runs in warm

standby mode.

When redundant NSP components are in geographically separate facilities, it is strongly

recommended that the active components are in the same facility. An NSP administrator can align

the active NSP components in a shared-mode deployment.

Redundancy in shared-mode deployments

To deploy the NSP as a redundant shared-mode system, each component of the system must be

redundant. For example, if a redundant NSP deployment includes the NFM-T, the NFM-T must be

deployed as a 1+1 redundant system. The NSP redundancy model can be 1+1 or 3+3, which is

known as high availability with disaster recovery, or HA with DR.

The following figure shows the NSP deployed as a 1+1 system.

NSP system redundancyNSP redundancy models

NSP


5.2 NSP Role Manager

5.2.1 Description

In a containerized DR NSP deployment, the Role Manager makes required changes to Kubernetes

objects as the site roles change between clusters. The Role Manager runs in the NSP cluster as a

Deployment resource. It follows the Kubernetes Controller pattern, reading from the store of

Kubernetes objects, listening for changes, and updating the objects as required based on the

current site role.

Figure 5-1 NSP components deployed using 1+1 redundancy

NSP Cluster - Site 2

App Tomcats

MDM Server

AssuranceTomcat

Login

Launchpad

Neo4j

PostgreSQL

nspOS

Kafka

Zookeeper

IPRC - Site 1

Tomcat

IPRC

Neo4j

NSP Cluster - Site 1

NFM-P - Site 1

App Tomcats

MDM Server

Assurance

MainApplicationServer

Oracle

NFM-P - Site 2

MainApplicationServer

Oracle

Data Synchronization

28347

Tomcat

Login

Launchpad

Neo4j

PostgreSQL

nspOS

Kafka

Zookeeper

IPRC - Site 1

Tomcat

IPRC

Neo4j

NE backup, stats,...

Oracle Dataguard

NSP system redundancyNSP Role Manager

NSP



20 Issue 1

5.2.2 Modes

The Role Manager has the following modes:

• standalone—The Role Manager sets the mode to 'active' at initialization time, and does nothing

more for the life of the pod.

• DR—The Role Manager negotiates the role with the DR peer.

The containerized NSP configuration file, nsp-config.yml, has the following section in which you

configure the NSP Role Manager; the example shows the default configuration, which is for a

standalone system.

dr:

dcName: "default"

mode: "standalone"

peer: ""

peerDcName: "site2"

5.2.3 REST APIs

The Role Manager supports the following REST APIs, which are used internally for inter-site calls,

but are also available for external use:

• GET /nsp-role-manager/server/status—returns the current status

• GET /nsp-role-manager/server/statusAll—returns the current status for the given site and the DR

peer, if present

• GET /nsp-role-manager/server/role?role=role&force=force—sets the role, where role is a string

value, and force is a Boolean value

• POST/PUT /nsp-role-manager/server/role—sets the role; the expected payload is a JSON object

that contains the role and force fields.

See the NSP DevOps Portal for more information.

5.3 NSP redundancy mechanisms and failure scenarios

5.3.1 Overview

The following topics describe NSP recovery actions in the event of a redundancy failure; a failure

scenario may apply to multiple shared-mode configurations, depending on which components are

deployed.

5.3.2 HA failure conditions

If an NSP cluster member permanently fails, for example, because of a hardware failure or disk

corruption, the member loses access to the cluster. If a cluster permanently loses more than (n-1)/2

members, where n is the number of cluster members, cluster quorum is lost. As a result, the cluster

cannot reach consensus, so cannot accept updates, and a cluster failure occurs.

NSP system redundancyNSP redundancy mechanisms and failure scenarios

NSP


File service pod failure

In an HA environment, when the active nsp-file-service pod restarts, or when a switchover to the

standby pod occurs, the NSP is not immediately available to service incoming file service requests.

The NSP file service requires several minutes to recover from a pod restart or switchover. Until the

primary pod is fully initialized, the NSP rejects incoming file-service requests, which must be retried

when the primary pod is available.

In the event of an NSP file-service pod switchover, the NSP raises the following alarm:

• fileServicePodSwitchOver

5.3.3 NSP disaster recovery

In a DR deployment, the NSP continually monitors the following NSP base services:

• Kafka

• nspos-tomcat

• PostgreSQL

• ZooKeeper

In addition, the IP resource control is monitored, and if unavailable, and activity switch occurs, after

which the peer NSP cluster and IP resource control each assume the primary role.

If any service in a DR deployment is unavailable for more than three minutes, or two instances of a

service in an HA/DR deployment are unavailable for more than three minutes:

• An activity switch occurs; consequently, the peer NSP cluster assumes the primary role.

• An alarm is raised against the service or containing pod to indicate that the service or pod is

down.

Note: This alarm may not be generated because of a base service disruption, depending on the

circumstances.

• A major ActivitySwitch alarm is raised against the former active site, which is now the standby

site.

The following are the Fault Management application alarms that the NSP raises against the

NmsSystem object in response to such a failure:

• ActivitySwitch—severity Major

• NspApplicationPodDown—severity Critical

Note: If you clear an alarm while the failure condition is still present, the NSP does not raise

the alarm again.

The following failure scenario example applies to a 1+1 DR deployment of redundant NSP sites at

geographically remote facilities.

1. An nspOS service at the primary site fails.

2. An activity switch occurs; the standby site consequently assumes the primary role.

3. A major ActivitySwitch alarm is raised against the former primary site, which is now the standby

site.


NSP



22 Issue 1

5.3.4 Primary NSP cluster failure

The redundant nsp-role-manager agents of the Role Manager exchange a heartbeat every five

seconds. If the agent on the standby cluster does not receive a heartbeat within 60 seconds, the

standby cluster is promoted to active. The new active cluster subsequently communicates with the

NFM-P and the newly active VSR-NRC. Primary cluster base services that stop running can also

trigger a switchover.

Note:When an NSP cluster switchover occurs, an IP resource control switchover also occurs.

Note: After an NSP cluster switchover, an internal selection process determines which NSP

Flow Collector Controller assumes the primary role.

Figure 5-2 Primary NSP cluster failure

Initial standby side

VSR-NRC

NFM-Pmain server

MDM

NSPCluster

MDM

IPRC


IP/MPLS

router

VSR-NRC

NFM-Pmain server

28344

MDM

NSPCluster

MDM

IPRC


NSP


5.3.5 NSP cluster communication failure

When communication between the NSP clusters fails, each NSP cluster assumes the active role,

which creates what is called a split-brain scenario. A 60-second loss of communication between the

primary and standby NSP clusters may trigger a switchover.

After communication in a split-brain scenario is restored, the NSP cluster with the higher uptime

value assumes the primary role, and the peer cluster assumes the standby role. The assumption is

that the cluster running for the longer time was the primary cluster at the time of the loss. In such a

scenario, the clients continue to communicate with the same primary cluster.

5.3.6 NFM-P main server failure

When the primary NFM-P main server becomes unavailable, the standby main server automatically

assumes the role of primary server. The NSP subsequently communicates with the new active main

server.

Figure 5-3 Primary and standby NSP cluster communication failure


VSR-NRC

NFM-Pmain server

MDM

NSPCluster

MDM

IPRC


IP/MPLS

router

VSR-NRC

NFM-Pmain server

28343

MDM

NSPCluster

MDM

IPRC

X


NSP



24 Issue 1

5.3.7 MDM fault tolerance

If an MDM server fails, an administrator must recover the MDM server on the NSP cluster member

that hosts the server. An MDM server is considered failed if both the number of protector pods

reaches zero and the number of active MDM pods is less than the number provisioned.

If an MDM cluster becomes degraded, which means that the number of available MDM protector

pods is less than the number provisioned, an administrator must bring up new active MDM servers

by doing one of the following:

• adding new servers to the NSP cluster

• repairing failed MDM servers

A failed MDM server that is restored to service assumes the standby role.

Figure 5-4 Primary NFM-P server goes down


VSR-NRC

NFM-Pmain server

MDM

NSPCluster

MDM

IPRC


IP/MPLS

router

VSR-NRC

NFM-Pmain server

28342

MDM

NSPCluster

MDM

IPRC


NSP


Note:When an NSP switchover occurs, an MDM switchover also occurs.

5.3.8 Primary VSR-NRC failure

NSP supports both single-site and dual-site deployments of redundant VSR-NRCs.

Single-site VSR-NRC deployment

The primary VSR-NRC communicates with the primary IP resource control. If the primary VSR-NRC

is unavailable, the primary IP resource control initiates communication with the VSR-NRC at the

standby site.

Dual-site VSR-NRC deployment

The primary VSR-NRC communicates with the primary IP resource control. If the primary VSR-NRC

is unavailable, the primary IP resource control initiates communication with the standby VSR-NRC

in the same data center.

Figure 5-5 Primary VSR-NRC failure in single-site deployment


NSP



26 Issue 1

TE-DB and LSP-DB synchronization

Full synchronization with the TE-DB and LSP-DB occurs whenever connection to a primary VSR-

NRC is successful. In other words, if the primary VSR-NRC becomes unavailable and the primary

NSP cluster begins to communicate with the standby VSR-NRC, the standby VSR-NRC is

promoted to primary, and full synchronization with the TE-DB and LSP-DB subsequently occurs.

PCC client communication

PCC clients can define primary and secondary VSR-NRC IP addresses, which enables the PCCs to

maintain communication without reconfiguration when the primary VSR-NRC becomes unavailable.

Figure 5-6 Primary VSR-NRC failure in a dual-site deployment


VSR-NRC

NFM-Pmain server

MDM

NSPCluster

MDM

IPRC


IP/MPLS

router

VSR-NRC

NFM-Pmain server

28345

MDM

NSPCluster

MDM

IPRC

X


NSP



NSP



28 Issue 1

A Standards compliance

A.1 Supported standards and interfaces

A.1.1 Industry standards and open-standard interfaces

The NSP incorporates industry standards and open-standard interfaces that allow interoperation

with other network monitoring and management systems. The NSP design incorporates the

standards and interfaces in the following table.

Table A-1 Industry standards and open-standard interfaces

Standard or interface Description

draft-alvarez-pce-path-profiles-04 PCE path profiles

draft-ietf-i2rs-yang-network-topo-20 A data model for network topologies

draft-ietf-idr-bgp-ls-segment-

routing-ext-04

BGP link-state extension for segment routing

draft-ietf-isis-segment-routing-

extenstions-04

IS-IS extensions for segment routing

draft-ietf-liu-netmod-yang-

schedule-04

A YANG data model for configuration scheduling

draft-ietf-ospf-segment-routing-

extensions-04

OSPF extensions for segment routing

draft-ietf-pce-segment-routing-08 PCEP extensions for segment routing

draft-ietf-pce-stateful-pce-14 PCEP extensions for stateful PCE

draft-ietf-teas-yang-te-10 A YANG data model for traffic engineering tunnels and

interfaces

draft-ietf-teas-yang-te-topo-13 YANG data model for TE topologies

OpenFlow OpenFlow Switch Specification version 1.3.1

REST Representational State Transfer

RFC 4655 Path Computation Element (PCE)

RFC 5101 Specification of the IP Flow Information Export (IPFIX)

Protocol for the exchange of IP traffic flow information

RFC 5102 Information model for IP flow information export

RFC 5440 Path Computation Element Communication Protocol

(PCEP)

Standards complianceSupported standards and interfaces

NSP


Table A-1 Industry standards and open-standard interfaces (continued)

Standard or interface Description

RFC 5575 Dissemination of flow specification rules

RFC 6020 YANG data modelling language for NETCONF

RFC 6021 Common YANG data types

RFC 6241 Network configuration protocol (NETCONF)

RFC 6242 NETCONF over SSH

RFC 6991 Common YANG data types

RFC 7223 A YANG data model for interface management

RFC 7224 IANA interface type YANG model

RFC 7420 PCEP Management Information Base (MIB) model

RFC 7684 OSPFv2 prefix/link attribute advertisement

RFC 7752 North-bound distribution of link-state and Traffic

Engineering (TE) information using BGP

RFC 7951 JSON encoding of data modelled with YANG

Standards complianceSupported standards and interfaces

NSP



30 Issue 1

B NSP data privacy summary

B.1 NSP network and user data privacy

B.1.1 Purpose

This appendix summarizes how the NSP treats private data that is collected, processed, or

retained, such as:

• user authentication data

• NE data

• subscriber data

• e-mail notification policy data

See B.1.2 “NSP data privacy” (p. 31) or B.1.3 “NFM-P data privacy” (p. 33) for specific summary

information.

B.1.2 NSP data privacy

The following table lists and describes, by category, how the NSP treats network and user data.

Table B-1 NSP treatment of private data

Data category Description and treatment

NE data

Type of data• Username and password

• IP address

Purpose• NE authentication

• NE IP address for NE discovery/access

Storage• Local database

• Logs

Retention Data is retained in the database until an authorized user deletes it. Log retention can vary

based on the log file size and number of log backups.

Processing NE data is processed for the stated purpose.

Access Authorized users

Safeguards• NEs are configured by authorized users.

• Database access is restricted to authorized users.

• Secure transit option is available.

• Passwords for NE users are encrypted before being stored.

• Log file access is restricted to authorized users.

NSP data privacy summaryNSP network and user data privacy

NSP


Table B-1 NSP treatment of private data (continued)

Data category Description and treatment

Subscriber data

Type of data• MAC address

• IP address

Purpose• Statistics

• SLA compliance

• Troubleshooting


• Logs

Retention Data is retained in the database until an authorized user deletes it. Log retention can vary

based on the log file size and number of log backups.

Retention period for statistics can be configured.

Processing Subscriber data is processed for the stated purpose.





E-mail notification policy data


• E-mail address (sender)

• E-mail address (recipient)

Purpose• Username, password and sender’s e-mail address are used for SMTP configuration

• Recipient e-mail addresses are required to create e-mail notification policies in supported

applications (for example, Fault Management application for alarm notifications)


Retention Data is retained in the database until an authorized user deletes it. By default, SMTP server

and application e-mail notification policies are not configured.

Processing SMTP server configuration and application e-mail notification policies are processed for the

stated purpose.


Safeguards• SMTP configuration and application e-mail policies are configured by authorized users.


• Password for SMTP configuration is encrypted before being stored.


NSP



32 Issue 1

B.1.3 NFM-P data privacy

The following table lists and describes, by category, how the NFM-P treats network and user data.

Table B-2 NFM-P treatment of private data

Category Description

Local user data (local authentication)


• E-mail

• IP address

Purpose• Authentication of local NSP users

• User e-mail addresses (optional) to send notifications for certain events; for example, alarms or account

status

• IP address provides accountability of individual product access.


• Logs

Retention Data is retained in the database until an authorized user deletes it. Log retention time can vary based on

log file size and the number of log backups.

Processing Local user data is processed for the stated purpose.


Safeguards• Additional local users must be created by an authorized user.


• TLS secures data in transit.

• Passwords for local users are hashed before they are stored.


Comments Local authentication is performed using a local database of users and a local security scheme.

Customer profile data

Type of data• Name

• E-mail

• Address

• Phone

Purpose Data may be used by an authorized user for associating customers to configured services.

Storage Local database

Retention Data is retained in the database until an authorized user deletes it.

Processing Customer profile data is processed for the stated purpose.



NSP


Table B-2 NFM-P treatment of private data (continued)


Safeguards• Customer profile must be created by an authorized user.


NE data


• IP address

Purpose• NE authentication

• NE IP address for NE discovery/access


• Logs

Note that NE backups that are stored on the NFM-P server may contain data that is not stored in the

NFM-P database. Data contained in the NE backup files will be dependent upon the NE type and version;

therefore the privacy statements for the individual NEs should be consulted.

Retention Data is retained in the database until an authorized user deletes it. Log retention can vary based on the log

file size and number of log backups.

Processing NE data is processed for the stated purpose.





• Passwords for NE users are encrypted before being stored.


Subscriber data

Type of data• MAC address

• IP address

• International Mobile Subscriber Identity (IMSI)

• International Mobile Station Equipment Identity (IMEI)

• Mobile Station International Subscriber Directory Number (MSISDN)

• Access Point Name (APN)

Purpose• Statistics

• SLA compliance

• Troubleshooting

• Analytics

• UE or network node performance information


NSP



34 Issue 1

Table B-2 NFM-P treatment of private data (continued)



• Logs

• Auxiliary collector servers (optional): statistics, PCMD, and call trace

• Analytics server (optional)

Retention Data is retained in the database until an authorized user deletes it. Log retention can vary based on the log

file size and number of log backups.

Retention period for auxiliary servers can be configured.

Processing Subscriber data is processed for the stated purpose.





• File access is restricted to authorized users.


E mail notification policies


• E-mail address (sender)

• E-mail address (recipient)

Purpose• Username, password and sender’s e-mail address are used for SMTP configuration

• Recipient e-mail addresses are required to create e-mail notification policies in supported applications

(for example, Fault Management application for alarm notifications)


Retention Data is retained in the database until an authorized user deletes it. By default, SMTP server and

application e-mail notification policies are not configured.

Processing SMTP server configuration and application e-mail notification policies are processed for the stated

purpose.


Safeguards• SMTP configuration and application e-mail policies are configured by authorized users.


• Password for SMTP configuration is encrypted before being stored.


NSP



NSP



36 Issue 1

C NSP RHEL OS compliance with CIS benchmarks

C.1 RHEL CIS benchmarks and NSP compliance

C.1.1 Purpose

This appendix describes the NSP compliance with the Center for Internet Security, or CIS, security

benchmarks for the RHEL OS.

C.1.2 RHEL 7 CIS compliance

Table C-1, “RHEL 7 CIS benchmarks and NSP compliance” (p. 38) lists the compliance of the

following with the CIS v2.2.0 RHEL 7 recommendations:

• NSP

• NFM-P

Note: The “qcow compliance” column indicates whether the NSP RHEL OS qcow2 image

conforms with the recommendation.

CIS profiles

The following CIS compliance profiles are referenced:

• Level 1—Server, or L1:

Intent of recommendations is to:

− be practical and prudent

− provide clear security benefit

− not inhibit utility of technology beyond acceptable degree

• Level 2—Server, or L2:

Extension of L1 profile; recommendations have one or more of the following characteristics:

− intended for environments or use cases in which security is crucial

− considered intensive defense measure

− may inhibit technology utility or performance

Note: It is strongly recommended that you maintain a log of all configuration changes that you

make regarding CIS compliance. Such a log may be of great value during system

troubleshooting. Each log entry must be dated and include the configuration details.

Compliance levels

The following indicate the level of compliance with a recommendation:

• Supported—The product is fully compliant.

• No expected impact—The product is not tested using the explicit recommendation, but the

product team foresees no effect on system functions.

NSP RHEL OS compliance with CIS benchmarksRHEL CIS benchmarks and NSP compliance

NSP


It is recommended that you test such a configuration to ensure that system operation is

unaffected; no commitment is offered to ensure product compatibility with a specific requirement.

• Partially supported—The product is conditionally compliant with the recommendation, as

described in the Notes column.

• Not supported—The product does not support the recommended configuration.

Table C-1 RHEL 7 CIS benchmarks and NSP compliance

Section Recommendation (scored,

unless otherwise noted)

Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

1 Initial Setup

1.1 Filesystem Configuration

1.1.1 Disable unused filesystems

1.1.1.1 Ensure mounting of

cramfs filesystems is

disabled

L1 Supported Yes —


freevxfs filesystems is

disabled


1.1.1.3 Ensure mounting of jffs2

filesystems is disabled


1.1.1.4 Ensure mounting of hfs




hfsplus filesystems is

disabled



squashfs filesystems is

disabled


1.1.1.7 Ensure mounting of udf


L1 Supported No —

1.1.1.8 Ensure mounting of FAT



1.1.2 Ensure separate partition

exists for /tmp

L2 Supported Yes Customer determines

appropriate partition size; disk

space cannot be taken from

partitions defined in NSP

deployment documentation


NSP



38 Issue 1

Table C-1 RHEL 7 CIS benchmarks and NSP compliance (continued)



Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

1.1.3 Ensure nodev option set

on /tmp partition


1.1.4 Ensure nosuid option set

on /tmp partition


1.1.5 Ensure noexec option set

on /tmp partition

L1 Not

supported

No noexec option cannot be set

on/tmp, which is required

forproduct installation

andconfiguration


exists for /var







exists for /var/tmp







on /var/tmp partition







L1 Not

supported

No noexec option cannot be set

on/var/tmp, which is required for

product installation and

configuration


exists for /var/log

L2 Supported No Customer determines






exists for /var/log/audit

L2 Supported No Customer determines






NSP





Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes


exists for /home


appropriate partition size;

diskspace cannot be taken from




on /home partition



on /dev/shm partition




L1 Not

supported

No Not supported by Oracle



L1 Not

supported

No Not supported by Oracle

1.1.21 Ensure sticky bit is set on

all world-writable

directories


1.1.22 Disable Automounting L1 Supported Yes —

1.2 Configure Software Updates

1.2.2 Ensure gpgcheck is

globally activated


1.3 Filesystem Integrity Checking

1.3.1 Ensure AIDE is installed L1 Not

supported

No May affect system performance

1.3.2 Ensure filesystem integrity

is regularly checked

L1 Not

supported

No Requires AIDE

1.4 Secure Boot Settings

1.4.1 Ensure permissions on

bootloader config are

configured


1.4.2 Ensure bootloader

password is set



NSP



40 Issue 1




Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

1.4.3 Ensure authentication

required for single user

mode

L1 No

expected

impact

Yes —

1.5 Additional Process Hardening

1.5.1 Ensure core dumps are

restricted

L1 Not

supported

No Core files required for customer

software support

1.5.2 Ensure XD/NX support is

enabled (not scored)


1.5.3 Ensure address space

layout randomization

(ASLR) is enabled


1.5.4 Ensure prelink is disabled L1 Supported Yes —

1.6 Mandatory Access Control

1.6.1 Configure SELinux

1.6.1.1 Ensure SELinux is not

disabled in bootloader

configuration

L2 Not

supported

Yes SELinux is not supported.

1.6.1.2 Ensure the SELinux state

is enforcing

L2 Not

supported

No SELinux is not supported.

1.6.1.3 Ensure SELinux policy is

configured

L2 Not

supported


1.6.1.4 Ensure SETroubleshoot is

not installed

L2 Not

supported


1.6.1.5 Ensure the MCS

Translation Service

(mcstrans) is not installed

L2 Not

supported


1.6.1.6 Ensure no unconfined

daemons exist

L2 Not

supported


1.6.2 Ensure SELinux is

installed

L2 Not

supported


1.7 Warning Banners

1.7.1 Command Line Warning Banners


NSP





Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

1.7.1.1 Ensure message of the

day is configured properly


1.7.1.2 Ensure local login warning

banner is configured

properly (not scored)


1.7.1.3 Ensure remote login

warning banner is

configured properly (not

scored)


1.7.1.4 Ensure permissions on

/etc/motd are configured

(not scored)



/etc/issue are configured



/etc/issue.net are

configured (not scored)


1.7.2 Ensure GDM login banner

is configured

L1 Supported No —

1.8 Ensure updates, patches,

and additional security

software are installed

L1 Partially

supported

No Applying RHEL patches is

supported, but compatibility

issues require backing out RHEL

updates until a fix is available.

Nokia does not recommend

installing any additional software

on the OS that hosts the NSP

because it may affect NSP

operation. Any non-sanctioned

software must be removed if the

software is suspected of causing

NSP issues.

2 Services

2.1 inetd Services

2.1.1 Ensure chargen services

are not enabled



NSP



42 Issue 1




Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

2.1.2 Ensure daytime services

are not enabled


2.1.3 Ensure discard services

are not enabled


2.1.4 Ensure echo services are

not enabled


2.1.5 Ensure time services are

not enabled


2.1.6 Ensure tftp server is not

enabled

L1 Supported Yes Supported, but TFTP may be

required for management of

some NE types

2.1.7 Ensure xinetd is not

enabled


2.2 Special Purpose Services

2.2.1 Time Synchronization

2.2.1.1 Ensure time

synchronization is in use

(not scored)


2.2.1.2 Ensure ntp is configured L1 Supported No Supported, but requires on-site

network information

2.2.1.3 Ensure chrony is

configured

L1 Supported No Supported, but requires on-site

network information

2.2.2 Ensure X Window System

is not installed

L1 Supported No Supported, but may affect ability

to run local GUI client on server

2.2.3 Ensure Avahi Server is not

enabled


2.2.4 Ensure CUPS is not

enabled


2.2.5 Ensure DHCP Server is

not enabled


2.2.6 Ensure LDAP server is not

enabled



NSP





Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

2.2.7 Ensure NFS and RPC are

not enabled


2.2.8 Ensure DNS Server is not

enabled


2.2.9 Ensure FTP Server is not

enabled


2.2.10 Ensure HTTP server is not

enabled


2.2.11 Ensure IMAP and POP3

server is not enabled


2.2.12 Ensure Samba is not

enabled


2.2.13 Ensure HTTP Proxy

Server is not enabled


2.2.14 Ensure SNMP Server is

not enabled


2.2.15 Ensure mail transfer agent

is configured for local-only

mode

L1 Supported No —

2.2.16 Ensure NIS Server is not

enabled


2.2.17 Ensure rsh server is not

enabled


2.2.18 Ensure talk server is not

enabled


2.2.19 Ensure telnet server is not

enabled


2.2.20 Ensure tftp server is not

enabled

L1 Supported Yes Supported, but TFTP may be

required for management of

some NE types

2.2.21 Ensure rsync service is

not enabled


2.3 Service Clients


NSP



44 Issue 1




Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

2.3.1 Ensure NIS Client is not

installed


2.3.2 Ensure rsh client is not

installed


2.3.3 Ensure talk client is not

installed


2.3.4 Ensure telnet client is not

installed


2.3.5 Ensure LDAP client is not

installed


3 Network Configuration

3.1 Network Parameters (Host Only)

3.1.1 Ensure IP forwarding is

disabled


3.1.2 Ensure packet redirect

sending is disabled


3.2 Network Parameters (Host and Router)

3.2.1 Ensure source routed

packets are not accepted


3.2.2 Ensure ICMP redirects are

not accepted


3.2.3 Ensure secure ICMP

redirects are not accepted


3.2.4 Ensure suspicious packets

are logged

L1 Supported Yes Supported, but may affect

system performance

3.2.5 Ensure broadcast ICMP

requests are ignored


3.2.6 Ensure bogus ICMP

responses are ignored


3.2.7 Ensure Reverse Path

Filtering is enabled



NSP





Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

3.2.8 Ensure TCP SYN Cookies

is enabled


3.3 IPv6

3.3.1 Ensure IPv6 router

advertisements are not

accepted (not scored)


3.3.2 Ensure IPv6 redirects are

not accepted (not scored)


3.3.3 Ensure IPv6 is disabled

(not scored)

L1 Supported No —

3.4 TCP Wrappers

3.4.1 Ensure TCP Wrappers is

installed


3.4.2 Ensure /etc/hosts.allow is

configured


network information

3.4.3 Ensure /etc/hosts.deny is

configured



/etc/hosts.allow are

configured



/etc/hosts.deny are 644


3.5 Uncommon Network Protocols

3.5.1 Ensure DCCP is disabled

(not scored)


3.5.2 Ensure SCTP is disabled

(not scored)


3.5.3 Ensure RDS is disabled

(not scored)


3.5.4 Ensure TIPC is disabled

(not scored)


3.6 Firewall Configuration


NSP



46 Issue 1




Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

3.6.1 Ensure iptables is installed L1 Supported Yes —

3.6.2 Ensure default deny

firewall policy


network information

3.6.3 Ensure loopback traffic is

configured

L1 Supported No —

3.6.5 Ensure firewall rules exist

for all open ports

L1 Supported No See the NSP firewall

requirements in the Security

section of the component

Planning Guide.

4 Logging and Auditing

4.1 Configure System Accounting (auditd)

4.1.1 Configure Data Retention

4.1.1.1 Ensure audit log storage

size is configured (not

scored)

L2 Supported No Default size (6MBytes)

recommended

4.1.1.2 Ensure system is disabled

when audit logs are full

L2 Supported No Supported, but not

recommended

4.1.1.3 Ensure audit logs are not

automatically deleted

L2 Supported No —

4.1.2 Ensure auditd service is

enabled


4.1.3 Ensure auditing for

processes that start prior

to auditd is enabled


4.1.4 Ensure events that modify

date and time information

are collected



user/group information are

collected



the system's network

environment are collected



NSP





Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes


the system's Mandatory

Access Controls are

collected

L2 Not

supported


4.1.8 Ensure login and logout

events are collected


4.1.9 Ensure session initiation

information is collected


4.1.10 Ensure discretionary

access control permission

modification events are

collected


4.1.11 Ensure unsuccessful

unauthorized file access

attempts are collected


4.1.12 Ensure use of privileged

commands is collected

L2 No

expected

impact

No —

4.1.13 Ensure successful file

system mounts are

collected


4.1.14 Ensure file deletion events

by users are collected

L2 Supported No Supported, but may affect

system performance

4.1.15 Ensure changes to system

administration scope

(sudoers) is collected


4.1.16 Ensure system

administrator actions

(sudolog) are collected


4.1.17 Ensure kernel module

loading and unloading is

collected


4.1.18 Ensure the audit

configuration is immutable


4.2 Configure Logging


NSP



48 Issue 1




Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

4.2.1 Configure rsyslog

4.2.1.1 Ensure rsyslog Service is

enabled


4.2.1.3 Ensure rsyslog default file

permissions configured


4.2.1.4 Ensure rsyslog is

configured to send logs to

a remote log host

L1 No

expected

impact

No Compliance requires on-site

network information.

4.2.1.5 Ensure remote rsyslog

messages are only

accepted on designated

log hosts. (not scored)

L1 Supported No An NSP server must not be

configured as a log host.

4.2.2 Configure syslog-ng

4.2.2.1 Ensure syslog-ng service

is enabled


4.2.2.3 Ensure syslog-ng default

file permissions configured


4.2.3 Ensure rsyslog or

syslog-ng is installed


4.2.4 Ensure permissions on all

logfiles are configured

L1 No

expected

impact

No —

5 Access, Authentication and Authorization

5.1 Configure cron

5.1.1 Ensure cron daemon is

enabled



/etc/crontab are

configured



/etc/cron.hourly are

configured



NSP





Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes


/etc/cron.daily are

configured



/etc/cron.weekly are

configured



/etc/cron.monthly are

configured



/etc/cron.d are configured


5.1.8 Ensure at/cron is

restricted to authorized

users

L1 Supported Yes Not supported on NFM-P

auxiliary database station

5.2 SSH Server Configuration


/etc/ssh/sshd_config are

configured

L1 Supported No —

5.2.2 Ensure SSH Protocol is

set to 2


5.2.3 Ensure SSH LogLevel is

set to INFO


5.2.4 Ensure SSH X11

forwarding is disabled

L1 Supported Yes Supported, but affects NSP client

operation if client uses SSH X11

forwarding

5.2.5 Ensure SSH

MaxAuthTries is set to 4

or less


5.2.6 Ensure SSH IgnoreRhosts

is enabled


5.2.7 Ensure SSH

HostbasedAuthentication

is disabled



NSP



50 Issue 1




Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

5.2.8 Ensure SSH root login is

disabled

L1 Not

supported

No Required for product installation

5.2.9 Ensure SSH

PermitEmptyPasswords is

disabled


5.2.10 Ensure SSH

PermitUserEnvironment is

disabled


5.2.11 Ensure only approved

MAC algorithms are used

L1 Supported Yes NOTE: If eNodeB NEs are

managed, hmac-sha1 must be

included.

5.2.12 Ensure SSH Idle Timeout

Interval is configured

L1 Not

supported

No May affect OSS client operation

5.2.13 Ensure SSH

LoginGraceTime is set to

one minute or less


5.2.14 Ensure SSH access is

limited

L1 No

expected

impact

No —

5.2.15 Ensure SSH warning

banner is configured


5.3 Configure PAM

5.3.1 Ensure password creation

requirements are

configured

L1 No

expected

impact

No —

5.3.2 Ensure lockout for failed

password attempts is

configured

L1 Supported No —

5.3.3 Ensure password reuse is

limited

L1 Supported No —

5.3.4 Ensure password hashing

algorithm is SHA-512


5.4 User Accounts and Environment

5.4.1 Set Shadow Password Suite Parameters


NSP





Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

5.4.1.1 Ensure password

expiration is 90 days or

less

L1 Partialy

Supported

No NOTE: The password expiration

period for NSP Linux users must

not be altered.

5.4.1.2 Ensure minimum days

between password

changes is 7 or more

L1 No

expected

impact

No —

5.4.1.3 Ensure password

expiration warning days is

7 or more


5.4.1.4 Ensure inactive password

lock is 30 days or less

L1 Partialy

Supported

No NOTE: The password expiration

period for NSP Linux users must

not be altered.

5.4.1.5 Ensure all users last

password change date is

in the past


5.4.2 Ensure system accounts

are non-login


5.4.3 Ensure default group for

the root account is GID 0


5.4.4 Ensure default user

umask is 027 or more

restrictive

L1 Not

supported

No —

5.4.5 Ensure default user shell

timeout is 900 seconds or

less

L2 Not

supported

No May affect OSS client operation

5.6 Ensure access to the su

command is restricted

L1 Not

supported

No —

6 System Maintenance

6.1 System File Permissions

6.1.1 Audit system file

permissions (not scored)

L2 Not

supported

No —


/etc/passwd are

configured



NSP



52 Issue 1




Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes


/etc/shadow are

configured



/etc/group are configured



/etc/gshadow are

configured



/etc/passwd- are

configured



/etc/shadow- are

configured



/etc/group- are configured



/etc/gshadow- are

configured


6.1.10 Ensure no world writable

files exist


6.1.11 Ensure no unowned files

or directories exist


6.1.12 Ensure no ungrouped files

or directories exist


6.2 User and Group Settings

6.2.1 Ensure password fields

are not empty


6.2.2 Ensure no legacy +

entries exist in

/etc/passwd



entries exist in

/etc/shadow



NSP





Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes


entries exist in /etc/group


6.2.5 Ensure root is the only

UID 0 account


6.2.6 Ensure root PATH Integrity L1 Supported Yes —

6.2.7 Ensure all users' home

directories exist


6.2.8 Ensure users' home

directories permissions

are 750 or more restrictive

L1 Partially

supported

Yes Not supported for NSP users.

6.2.9 Ensure users own their

home directories


6.2.10 Ensure users' dot files are

not group or world writable


6.2.11 Ensure no users have

.forward files



.netrc files


6.2.13 Ensure users' .netrc Files

are not group or world

accessible



.rhosts files


6.2.15 Ensure all groups in

/etc/passwd exist in

/etc/group


6.2.16 Ensure no duplicate UIDs

exist


6.2.17 Ensure no duplicate GIDs

exist


6.2.18 Ensure no duplicate user

names exist



NSP



54 Issue 1




Pro-

file

Compli-

ance level

qcow

compli-

ance

Notes

6.2.19 Ensure no duplicate group

names exist



NSP



NSP



56 Issue 1

NSP Network Services Platform Release 20.9 System ...

Documents

Transcript of NSP Network Services Platform Release 20.9 System ...