In this section:

Overview

The DSC offers many security features to ensure authenticated access to functions appropriate for each user and the audit of the work performed by these users. The Telcordia GR-815-CORE: Generic Requirements for Network Elements/Network Systems (NE/NS) Security standard has been used as a guide for the implementation of the security features.

The DSC is typically placed in an access controlled corporate network and physically installed in a secure customer site.

Access to the DSC is described in Operation, Administration, and Maintenance.

Note

Remote access to the DSC Platform is only possible after you have installed the system and configured the IP addresses on the Management and Routing CPUs or Management and Routing VMs (VM1 and VM2). For more information about the installation process and system access, refer to the appropriate chapter in the Installation Guides.

The following sections provide an overview of the DSC security features.

User Identification and Authentication

All users accessing the DSC must sign on with a User ID and password provided by the given company's system administrator. This administrator also assigns access privileges to those accounts. For more information about configuring user profiles and privileges, refer to DSC User Profiles and Privileges.

The DSC password policy minimizes the risks associated with unauthorized system access by enforcing the following:

Password Policy EnforcementMore information

Inability to access the system (lockout) after five consecutive login attempts with the incorrect password

Lockout of the System When Using an Incorrect Password

Selecting passwords with defined guidelines

Password Restrictions

Password aging to force a password change after a configurable time interval

Password Aging

Forced password change for new users at first login

Password Change on First Login

Enforced password complexity rules

Password Restrictions

Enforced non-reuse of previous password

Password Reuse

User Access Privileges

When a user account is created by the system administrator, the account is assigned a level of access so that the user may have read-only access, or may have their actions restricted to only certain parts of the functionality.  For example, one may want to have a user who can modify Global Title Translation data, but who cannot add and delete links.

The DSC supports the following user profiles:

  • Root (ROOT)
  • SS7 Administrator (SS7_ADMIN)
  • MTP Operator (MTP_OPERATOR)
  • SCCP Operator (SCCP_OPERATOR)
  • Read-only (MONITOR)
  • Unprofiled (UNPROFILED)
Note

It is recommended that the ROOT user adds all system users with the appropriate user profile and provides these users with initial passwords. For information about password restrictions, see DSC Password Management

User names are less than or equal to 31 characters. User names can contain alphanumeric, period, and hyphen characters. 

For more information about managing users, refer to Managing DSC - SP2000 Users

For more information about user access privileges, refer to DSC User Profiles and Privileges.

Automatic User Log Off

If a Web UI session or terminal has had a period of inactivity, that session is automatically logged off. The system administrator can modify the length of time for the inactivity to occur before automatic log off happens.

For detailed information about Automatic Log Off, refer to Password Aging

Audit Trail of User Activity

Users provisioning and working with signaling data and system data have their activities logged. Both Web actions and Linux command activity is tracked allowing the system administrator to see who performed actions or modified the system configuration. This feature also provides data for troubleshooting and security audits.

The following files are automatically monitored using the audit trail functionality:

  • /etc/
  • /opt/cpu_ss7gw/current/data/

  • user commands executed at the Linux prompt

For detailed information about audit trail of user activity, refer to Audit Trail for User Activity.

Secure Shell and Secure FTP

Access to the operating system of the DSC is performed by Secure Shell (SSH) or Secure File Transfer Protocol (SFTP). These access methods provide for encryption which greatly diminishes the risk associated with packet sniffing.

For detailed information about Secure Shell and Secure FTP, refer to Configuring Secure Shell and Secure FTP.

IPsec

IPsec protocol suite is the method for DSC intra-realm security. This protocol suite provides encryption between two IP endpoints. For more information about this protocol, refer to Configuring IPsec.

Note

IPsec is configurable on an address to address basis.

Transport Layer Security

Transport Layer Security (TLS) and datagram TLS (DTLS) are the methods for DSC inter-realm security. These encryptions are done between Diameter applications and are easier for use across a wider network.

TLS and datagram TLS are application-specific and must be configured within the given application (refer to TLS Provisioning Process).

Firewalls

The DSC firewall is designed using the IP tables Linux firewall implementation and some proprietary configuration, start-up scripts, and data files to only allow access to necessary system functions. The firewall is enabled by default after the initial configuration procedure is executed. After the firewall is enabled, the only access to the system is through the TL1 port, SSH, and the Web UI. 

The DSC Platforms have been designed with the following firewall functionality:

  • TCP and UDP traffic is highly restricted
  • Insecure traffic on TCP and UDP is limited to outgoing NTP, SNMP (in for provisioning and out for traps), outgoing SMTP (possible E-mail backups), and outgoing syslog (external log capture)
  • Secured traffic on TCP and UDP includes SSH and HTTP (which is automatically redirected to HTTPS), and HTTPS. Also, secured traffic related to IPsec are allowed (ESP, AH)
  • SCTP is open by default

Open IP Ports

The following are the IP ports open on the DSC:

  • SSH (22)
  • HTTP (80) and HTTPS (443)
  • SNMP(161,162)
  • SMTP (25)
  • NTP (123)
  • SYSLOG (514) 

These ports may be closed as required.

Monitoring and Tracing Security Information

  • Audit trail (audit_trail) is used to analyze user activities on the SS7 provisioning. This includes creating, deleting, and modifying SS7 layer parameters and objects as well as any actions committed using these applications.  As a user performs provisioning activity in the SS7 stack, each action along with the timestamp and the account name is written to the audit trail log file.
  • Secure log (secure). This log stores SSH and SFTP-related information. It gives the authentication logs for users who access the Operating System of the DSC. The DSC is designed so that users do not need to access the LINUX prompt. The Administrator can control user privileges to determine who can reach the LINUX prompt. However, accessing the LINUX prompt on a running system is not required.
  • Messages log (messages). The messages log is based on the Linux Operating system used by the DSC. This log stores information on scheduled process startup such as cleanup scripts and audits.
  • SNAMI log (gr310audit). This log captures every single incoming GR310 command and single GR310 response transmitted from the DSC 8000.

The following log files are not strictly related to Security, but are included below to complete the information on the log files used:

  • System log (ptisyslog). This log stores service-affecting (alarms) and non-service-affecting (significant events) conditions. PTISyslog is based on the Linux operating system “syslog” daemon, which allows this log information to be forwarded to any similarly configured Linux or UNIX systems. 
  • Debug log (ptidbglog). The debug log is a similar mechanism to the syslog. The amount of data sent to this log can be controlled through various configuration parameters and through the MSU Tracing feature.  This log is used for troubleshooting purposes. The messages displayed in this log through the MSU Tracing feature may be used for troubleshooting purposes by the customer.  This log also contains details used by the Customer Support personnel for troubleshooting purposes.
  • Boot log (boot.log). This log stores system boot information.
  • Heartbeat (heartbeat). This log stores information regarding high availability mechanisms such as the Heartbeat application which keeps track of the network status (the status of the Ethernet ports).


  • No labels