Contents
1 Introduction
This document describes the security functions implemented by the Call Session Control Function (CSCF). It also describes the security-related procedures that can be performed by the system administrators.
The CSCF is an essential module in the IP Multimedia Subsystem (IMS) for processing signaling data, using the Session Initiation Protocol (SIP) and Diameter as signaling protocols. It supports Internet Protocols on a scalable and high-performance platform. The CSCF can be deployed as a virtual network element in an IMS network. For details about the CSCF, the supported functionality, and the nodes it communicates with, refer to CSCF Technical Description.
1.1 Prerequisites
This section describes the conditions required for performing security management on the CSCF.
1.1.1 Conditions
Before performing the procedures in Section 3.1 Procedures, the following conditions must apply:
- The CSCF Virtual Network Function (VNF) is installed and initially configured. The initial configuration includes the necessary settings for the authentication of the Northbound Interface (NBI) users and their authorization.
- The intended software level to be run in the CSCF is installed. The release information can be found in delivery reports, delivery specifications, delivery notes, release notes, or correction notes.
- The user has the required access privileges, and the required usernames and passwords are known.
- A System Security Administrator access role is required.
1.2 Environment
This section describes the environment requirements for product operations.
The CSCF belongs to the IP Multimedia Core Network (IMCN) and it is indirectly connected to the access network by the Session Border Gateway (SBG), which offers firewall capabilities and provides protection from external attacks.
The CSCF is placed in the Service & Control Virtual Private Network (VPN) group, which includes Network Functions handling signaling traffic without direct connection to external networks.
The following VPNs exist in the group:
- The Signaling Service Control VPN for signaling traffic to and from other IMS Network Nodes.
- The Operation and Maintenance Service Control VPN for Operation & Maintenance (O&M) traffic used for IMS Network nodes in the group.
- Charging VPN for offline (Rf) and online (Ro) traffic.
For more details, refer to CSCF VNF Network Connectivity Overview.
2 Product Security Functionality
The following security functionality is supported in the product:
- Authentication
- Authorization
- Accountability
- Integrity
- Confidentiality
2.1 Authentication
2.1.1 Subscriber Authentication
The CSCF supports the following authentication procedures:
- IMS Authentication and Key Agreement (AKA)
- Authentication through trusted gateway
- Authentication through trusted Application Server (AS)
- NASS Bundled Authentication (NBA)
- GPRS IMS Bundled Authentication (GIBA)
- Digest authentication
- Optimized Digest
2.1.2 O&M User Authentication
The CSCF supports O&M password-based and key-based user authentication. For more information, refer to User Management.
2.1.3 Mutual Authentication of Communication Channel Peers
The CSCF supports certificate-based mutual authentication for the following:
- Lightweight Directory Access Protocol (LDAP) over Transport Layer Security (TLS), between the CSCF and the LDAP server, refer to Certificate Management.
- Internet Key Exchange version 2 (IKEv2) during the establishment of the IP Security (IPsec) Security Associations, between the CSCF and any peer, refer to eVIP Management Guide.
2.2 Authorization
The CSCF supports O&M User Authorization.
Authorization is the capability to validate if the logged in user is allowed to perform a certain operation to a certain Managed Object (MO). The authorization is role-based, that is, the logged in user is mapped to a role and each role has one or several rules defining the access right to an MO.
For a description of the user management principles, user administration, and user roles, refer to User Management.
2.3 Accountability
The audit log enables logging and tracking access to files, directories, and resources of the system, as well as tracing system calls. It enables oversight of the system for application misbehavior or code malfunctions.
For more information, refer to Audit Information.
2.4 Integrity
2.4.1 Node Integrity
The CSCF supports node integrity in the following ways:
- Verify and protect the integrity of the system configuration files.
- Protect and prevent unauthorized modification of the selected files or folders.
- O&M Roles and Rules provide integrity protection by role and target-based access control.
2.4.2 Communication Integrity
The CSCF supports communication integrity in the following ways:
- Integrity protection of O&M traffic (also including Charging Data Records, backups, logs)
- Integrity protection of signaling traffic
- TLS provides for integrity protection
2.5 Confidentiality
The CSCF supports communication confidentiality in the following ways:
- Confidentiality protection of O&M traffic (including Charging Data Records, backups, logs)
- Confidentiality protection of signaling traffic
- TLS provides for confidentiality and integrity protection, and mutual authentication of the peers
- NETCONF is protected using Secure Shell (SSH), and TLS can also be used
- Signaling traffic like SIP and Diameter can be protected by IPsec tunnels with authentication
3 Security Configuration
3.1 Procedures
This section provides the instructions for operating the security functionality of the product.
3.1.1 Hardening
Perform hardening of the CSCF node according to the procedures, refer to CSCF Hardening Guideline, including the following steps:
- Allow or block ports for all listening services
- Change default passwords, including predefined password for root that can be known by many persons
- Disable root access through NBI, remote logon for root user is enabled by default
- Enable strong password enforcement
- Force password change and aging
- Configure Ericsson Command-Line Interface (ECLI) inactivity timer
- Create emergency user, at least one emergency user must be configured in the system
- Delete unused local Linux® accounts, if additional users are created during installation, and they are not to be used, they must be deleted
- Block Network File System (NFS) against access from external networks
The operator can have their own security policies, where the node must be hardened according to operator requirements, for example, defining specific secure protocols or other ports different than the default ones.
After the hardening activities have been performed, create a backup of the system and upload the backup to external storage.
3.1.2 Authentication and User Management
For instructions on how to create users and user groups, and assign privileges to a group, refer to User Management. Always use personal accounts instead of shared or generic user accounts.
The CSCF has the following predefined default roles. The roles, and the corresponding rules, cannot be modified:
- CSCF Application Administrator
- CSCF Application Operator
- CSCF Application Security Administrator
- Local Authentication Administrator
- Self
- System Administrator
- System Read Only
- System Security Administrator
LDAP must be configured with the strongest possible ciphers.
For details on LDAP Authentication, Local Authorization, Roles, and Rules, refer to User Management.
3.1.3 Audit Trails
The audit log enables logging and tracking access to files, directories, and resources of the system, as well as tracing system calls. It enables oversight of the system for application misbehavior or code malfunctions.
For information about where to find the audit and syslog log files, and how to read them, refer to Audit Information.
3.1.4 Change Logon Banner
By default, no information is provided to the user when logging on using the Command-Line Interface (CLI). The operator can define their own customized greeting message or legal message when a user logs on through the CLI.
The system provides the file /cluster/etc/motd, which allows a text message to be created and later displayed when user logs on to the system through CLI.
3.1.5 IPsec Support
If there are requirements to protect Signaling traffic, for example, SIP or Diameter (when transferring charging or malicious call tracing data), IPsec tunnels can be used.
For a description of the procedures for setting up IPsec tunnels to protect signaling traffic, refer to eVIP Management Guide.
3.2 Recommended Periodic Operations
The product must be properly hardened before it is taken into use. Nevertheless, it is important that the daily operations on the product are performed in such a way that the security status of the product is not weakened.
New vulnerabilities that must be mitigated are frequently found in the existing products. Therefore it is necessary to maintain the security posture of the product in service on a regular, ongoing basis.
The recommended periodic security-related operations are the following:
- Ensure that the latest software version is installed. Get the latest available Emergency Package (EP) version of the CSCF.
- Perform system backups regularly.
- Export backups to external storage regularly.
- Export logs to external storage regularly.
- Fetch Performance Management (PM) data from the CSCF regularly and store externally.
- Check the TLS certificates regularly to ensure that they do not expire.
- Run password checkers periodically to find weak passwords.
This is done using third-party software.
- Note:
- Do not install third-party software tools as part of the CSCF distribution.
- Monitor the file system integrity periodically, either manually or as a scheduled task. For more information, refer to CSCF Health Check.
- Ensure that no unnecessary listening ports are open, for example, by using external tools such as "Nessus" to monitor the ports and check with the system documentation or by checking the system manually.
- Ensure that the ports for the insecure protocols Telnet and File Transfer Protocol (FTP) are closed.
- Ensure that no shared user accounts are used.
- Ensure that administrative user rights are assigned only to real needs.
- Check the audit logs that are related to potential security events regularly. Check anything that can be considered as strange according to the traffic model of the operator besides error cases, such as failures to authenticate, too much user activity, and too many dropped or rejected sessions.
- Analyze log data and counters regularly to reconsider the chosen security-related attributes.
3.3 Handling of Patches
Patches are delivered in the form of EPs. The process to load EPs is described in the upgrade instruction for the actual CSCF EP.
4 Default Parameter Values
The default values for the security parameters are listed in Table 1.
|
Parameter |
Default Value |
|---|---|
|
Not Applicable |
No default values |
5 Services, Ports, and Protocols
This section provides information about network services in the system that are available from External Networks.
5.1 Listening Services
The listening services are shown in Table 2.
|
Port |
Protocol |
Description |
Listening Only on the Internal Network |
|---|---|---|---|
|
22 |
Secure Shell (SSH/Secure File Transfer Protocol (SFTP)) |
No, configurable | |
|
67 |
Dynamic host configuration service (DHCP) |
Yes | |
|
69 |
File transfer service (TFTP) |
Yes | |
|
111 |
TCP/UDP |
Portmap service (portmap) |
No. The service is listening on the External Network, but it is serving only on the internal network. |
|
123 |
Time synchronization service (NTP) |
No | |
|
514 |
Log service (syslog) |
Yes | |
|
1022 |
SSH/SFTP (only for LDEwS) |
Yes | |
|
1128 |
Alarm service |
Yes | |
|
1129–1131 |
TCP/UDP |
Node service |
Yes |
|
2049 |
TCP/UDP |
Network File System (NFS) |
No. The service is listening on the External Network, but it is serving only on the internal network. |
|
7788 |
Disk replication service (DRBD) |
Yes |
The standard SSH server is started up by Linux Distribution Extensions (LDE) with a default configuration, listening on default port 22 on all networks. Also on Linux Distribution Extensions with SUSE™ Linux Enterprise Server (LDEwS), a second SSH server is listening on port 1022 on the internal network.
5.2 External Traffic Port Numbers
The ports listed in Table 3 must be available for external SIP and DNS traffic through the External Network Traffic VIP interfaces. The Access List, as part of the firewall policy in the VIP Gateway Router, is used to accomplish this availability. How to configure the router Access List depends on which router is used and is described in the documentation for the specific router chosen. These ports are used for If1, ISC, Ma, Mw, Mg/Mj, Mr, and Ml interfaces. Other VIP Gateway Routers belonging to Operation and Maintenance (O&M), Charging, and Signaling Networks must block the access to the listed external ports in Table 3.
|
Port Number |
Protocol |
Server Side |
Use (Comment) |
|---|---|---|---|
|
53 |
DNS server |
||
|
53 |
DNS server |
||
|
5060 |
For SIP used by I-, S-, or E-CSCF, or EATF, or BCF, other port numbers can be used. | ||
|
5060 |
For SIP used by I-, S-, or E-CSCF, or EATF, or BCF, other port numbers can be used. |
5.3 Operation and Maintenance Port Numbers
The ports listed in Table 4 must be available through O&M VIP Interface. The Access List, as part of the firewall policy in the O&M VIP Gateway Router, is used to accomplish this availability. How to configure the router Access List depends on which router is used and is described in the documentation for the specific router chosen. All the VIP Gateway Routers belonging to Charging and HSS/SLF must block the access to the listed external ports in Table 4.
|
Port Number |
Protocol |
Server Side |
Use (Comment) |
|---|---|---|---|
|
161 |
SNMP requests to Platform (Fault Management). | ||
|
162 |
SNMP traps (messages) from Platform to SNMP Manager. Port number is configurable in Platform. | ||
|
830 |
NETCONF | ||
|
2022 |
|||
|
2028 |
|||
|
6513 |
NETCONF over TLS |
5.4 Diameter Port Numbers
The ports listed in Table 5 must be available through the Charging or Signaling Diameter VIP interface. The Access List, as part of the firewall policy, in the Charging or Signaling Diameter VIP Gateway Router is used to accomplish this availability. How to configure the router Access List depends on which router is used and is described in the documentation for the specific router chosen. These ports are used for Charging or Signaling Diameter networks. All the VIP Gateway Routers belonging to Traffic and O&M Networks must block the access to the listed external ports in Table 5.
|
Port Number |
Protocol |
Server Side |
Use (Comment) |
|---|---|---|---|
|
3868 |
CSCF Diameter |
Default Diameter port | |
|
3869(1) |
CSCF Diameter |
Additional Diameter port | |
|
3870 (1) |
CSCF Diameter |
Additional Diameter port | |
|
3871 (1) |
CSCF Diameter |
Additional Diameter port | |
|
3872 (1) |
CSCF Diameter |
Additional Diameter port |
(1) Port numbers 8700–8732
can also be used
5.5 SIP IP Flows
SIP IP flows are described in Section 5.5.1 Ma Interface, Section 5.5.2 Mw Interface, Section 5.5.3 Mg/Mj Interface, Section 5.5.4 Ml Interface, Section 5.5.5 Mr Interface, Section 5.5.6 ISC Interface, Section 5.5.7 I4 Interface, and Section 5.5.8 I5 Interface.
The ports listed in the following subsections are configurable for all the external interfaces. The default port for SIP is 5060 according to RFC 3261 SIP: Session Initiation Protocol.
- Note:
- The CSCF originating port for TCP is ephemeral for outgoing traffic to the remote nodes. Therefore, the origin port for the TCP is not applicable in the tables in the subsections.
5.5.1 Ma Interface
The flows that must be available on the Ma interface are shown in Table 6.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
Allocated ports to the AS |
I-CSCF port |
||||
|
I-CSCF port |
Any |
5.5.2 Mw Interface
The flows that must be available on the Mw interface are shown in Table 7.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
I-CSCF Mw port |
S-CSCF port |
||||
|
BCF Mw port |
S-CSCF port |
||||
|
I-CSCF Mw port |
Any |
||||
|
S-CSCF Mw port |
Any |
||||
|
P-CSCF Mw port |
E-CSCF port |
5.5.3 Mg/Mj Interface
The flows that must be available on the Mg/Mj interface are shown in Table 8.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
MGC Mj port |
I-CSCF port |
||||
|
MGC Mj port |
S-CSCF port |
||||
|
MGC Mj port |
E-CSCF port |
||||
|
MGC Mj port |
BCF/I-CSCF VIP |
BCF/I-CSCF port |
|||
|
I-CSCF Mj port |
Any |
||||
|
S-CSCF Mj port |
Any |
||||
|
E-CSCF Mj port |
Any |
5.5.4 Ml Interface
The flows that must be available on the Ml interface are shown in Table 9.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
E-CSCF MI port |
LRF Port number |
HTTP/SIP | |||
|
LRF MI port |
E-CSCF Port Number |
HTTP/SIP |
5.5.5 Mr Interface
The flows that must be available on the Mr interface are shown in Table 10.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
MRF Mr port |
I-CSCF port |
||||
|
MRF Mr port |
S-CSCF port |
||||
|
I-CSCF Mr port |
Any |
||||
|
S-CSCF Mr port |
Any |
5.5.6 ISC Interface
The flows that must be available on the ISC interface are shown in Table 11.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
S-CSCF port |
|||||
|
Any |
5.5.7 I4 Interface
The flows that must be available on the I5 interface are shown in Table 12.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
E-CSCF I4 port |
EATF Port number |
||||
|
EATF I4 port |
E-CSCF Port number |
5.5.8 I5 Interface
The flows that must be available on the I5 interface are shown in Table 13.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
I-CSCF I5 port |
EATF Port number |
||||
|
EATF I5 port |
I-CSCF Port number |
5.6 DNS IP Flows
DNS IP flows are described in Section 5.6.1 If1 Interface.
The ports listed in the following subsections are configurable for all the external interfaces. The default port for SIP is 5060 according to RFC 3261 SIP: Session Initiation Protocol.
- Note:
- The CSCF originating port for TCP is ephemeral for outgoing traffic to the remote nodes. Therefore, the origin port for the TCP is not applicable in the tables in the subsections.
5.6.1 If1 Interface
The flows that must be available on the If1 interface are shown in Table 14.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
I-CSCF If1 port |
Any |
UDP/TCP | |||
|
S-CSCF If1 port |
Any |
UDP/TCP | |||
|
E-CSCF If1 port |
Any |
UDP/TCP | |||
|
EATF If1 port |
Any |
UDP/TCP | |||
|
BCF If1 port |
Any |
UDP/TCP |
5.7 Diameter IP Flows
Diameter IP flows are described in Section 5.7.1 Cx and Dx Interfaces, Section 5.7.2 Rf Interface, Section 5.7.3 Ro Interface, and Section 5.7.4 Sh and Dh Interface.
The ports listed in the following subsections are configurable for all the external interfaces. The default port for SIP is 5060 according to RFC 3261 SIP: Session Initiation Protocol.
- Note:
- The CSCF originating port for TCP is ephemeral for outgoing traffic to the remote nodes. Therefore, the origin port for the TCP is not applicable in the tables in the subsections.
5.7.1 Cx and Dx Interfaces
The flows that must be available on the Cx and Dx interfaces are shown in Table 15.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
Cx | |||||
|
HSS Cx stack port |
I-CSCF CSCFCX stack port |
||||
|
HSS Cx stack port |
S-CSCF CSCFCX stack port |
||||
|
HSS Cx stack port |
BCF CSCFCX stack port |
||||
|
I-CSCF CSCFCX stack port |
Any |
||||
|
S-CSCF CSCFCX stack port |
Any |
||||
|
BCF CSCFCX stack port |
Any |
||||
|
Dx | |||||
|
SLF Dx stack port |
I-CSCF CSCFDX stack port |
||||
|
SLF Dx stack port |
IS-CSCF CSCFDX stack port |
||||
|
I-CSCF CSCFDX stack port |
Any |
||||
|
S-CSCF CSCFDX stack port |
Any |
||||
5.7.2 Rf Interface
The flows that must be available on the Rf interface are shown in Table 16.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
Offline Charging System to S-CSCF (Diameter) |
IP address range or ranges allocated to Offline Charging system. |
Offline Charging System CSCFRF stack port |
S-CSCF CSCFRF stack port |
||
|
Offline Charging System to E-CSCF (Diameter) |
IP address range or ranges allocated to Offline Charging system. |
Offline Charging System CSCFRF stack port |
E-CSCF CSCFRF stack port |
||
|
S-CSCF to Offline Charging System (Diameter) |
S-CSCF CSCFRF stack port |
IP address range or ranges allocated to Offline Charging system. |
Any |
||
|
E-CSCF to Offline Charging System (Diameter) |
E-CSCF CSCFRF stack port |
IP address range or ranges allocated to Offline Charging system. |
Any |
5.7.3 Ro Interface
The flows that must be available on the Ro interface are shown in Table 17.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
Online Charging System to S-CSCF (Diameter) |
IP address range or ranges allocated to Online Charging System. |
Online Charging System CSCFRO stack port |
S-CSCF CSCFRO stack port |
||
|
S-CSCF to Online Charging System (Diameter) |
S-CSCF CSCFRO stack port |
IP address range or ranges allocated to Online Charging System. |
Any |
5.7.4 Sh and Dh Interface
The flows that must be available on the Sh and Dh interfaces are shown in Table 18.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
HSS Sh/Dh port |
E-CSCF CSCFCX stack port |
||||
|
E-CSCF CSCFCX stack port |
Any |
5.8 IP Flow through DUA-DB LDAP
The flows that must be available on the DUA-DB LDAP interface are shown in Table 19.
|
Traffic Flow |
Origin IP |
Origin Port |
Destination IP |
Destination Port |
Protocol |
|---|---|---|---|---|---|
|
LDAP Port number |
6 Privacy
The CSCF handles personal subscriber data to be able to provide services in the network. The personal subscriber data is handled in a secure way and the product supports different measures to protect the privacy of the subscribers. The CSCF stores personal subscriber data that is read from the Home Subscriber Server (HSS) when a subscriber registers and uses the personal subscriber data received through signaling for IMS session handling. Charging data is collected and sent to an external system for billing. Personal subscriber data can also be stored in logs when specific events happen in the system. For a description of the personal subscriber data that is handled by the CSCF, see Section 6.4 Classification of Personal Subscriber Data.
6.1 Notice
This product processes personal subscriber data. Depending on the local legislation where the product is deployed and operated, the use of this product can require providing notice of the privacy policy of the operator to subscribers.
Ericsson discloses personal subscriber data to customers, professional advisors, suppliers, or other third parties engaged to perform administrative or other business management services. This disclosure is always on a confidential basis or otherwise in accordance with law. Ericsson may also disclose personal subscriber data with the consent of the individual or if disclosure is required or authorized by law.
Ericsson takes reasonable steps in all circumstances to ensure that the personal subscriber data it holds is protected from misuse, from interference and loss, and from unauthorized access, modification, or disclosure. Ericsson holds personal subscriber data in both hard copy and electronic forms in secure databases on secure premises, accessible only by authorized personnel.
Ericsson destroys or de-identifies personal subscriber data in circumstances where it is no longer required, unless Ericsson is otherwise required or authorized by law to retain that data.
6.2 Consent
This product processes personal subscriber data. Depending on the local legislation where the product is deployed and operated, the subscriber must give consent upon buying this service to do the following:
- Collect and maintain personal subscriber data, aimed at holding securely this information.
- Fulfill the purpose of installing, upgrading, and administering
the CSCF.
The system can be required to activate trace information. The purpose of these traces is only for troubleshooting. Depending on the trace level, it can contain personal subscriber data.
The collected data is only be accessed by Ericsson personnel or specific third parties that are in charge of these activities. The collected data is not distributed to third parties for other purposes.
When the personal subscriber data is no longer required, this data is disposed of.
6.3 Handling of Personal Subscriber Data
6.3.1 Personal Subscriber Data in Logs
6.3.1.1 Personal Subscriber Data in the CSCF Cache
Subscriber data is cached by the CSCF during call handling. The REGISTRATION message has a time limit for the cached data. After the time expires, the data is deleted.
The CSCF also removes the cached subscriber data when the user deregisters successfully.
6.3.1.2 Personal Subscriber Data in the CSCF Console Logs
The CSCF writes events that are used during troubleshooting to log files. These log files are reused and overwritten when the maximum file size limit and the maximum number of log files are reached.
The following are the CSCF console logs and their storage locations:
- Syslog: /var/log/<system_controller>
- CSM log: /cluster/storage/no-backup/coremw/var/log/<system_controller>/clustermonitor
- vDicos console logs: /cluster/storage/no-backup/cdclsv/log/lpmsv/
These log files can contain privacy data.
- Application logs: /cluster/storage/no-backup/coremw/var/log/saflog/
These log files can contain privacy data.
- Crashcollector: /cluster/storage/no-backup/cdclsv/dumps/
These log files can contain privacy data.
The management policy of the CSCF console log files is described in Handling Files.
6.3.1.3 Personal Subscriber Data in Other CSCF Logs
The data collections from ACDC and Health Check are generated by operator interaction only. These log files are not reused or overwritten.
Additional logs can be found in the following locations:
- Data Collection (ACDC): /cluster/storage/no-backup/vcscf_<CSCF_Product_Number>/acdc/
For example: /cluster/storage/no-backup/vcscf_CXP9034345/acdc/
- Health Check Reports: /cluster/storage/no-backup/vcscf_<CSCF_Product_Number>/healthcheck/
For example: /cluster/storage/no-backup/vcscf_CXP9034345/healthcheck/
For more details on how to collect data using the Aggregated CSR Data Collection (ACDC) script, refer to Data Collection Guideline for CSCF.
6.3.2 CSCF Functions with Privacy Impact
The following CSCF functions collect personal subscriber data:
- Offline and Online Charging
The CSCF collects offline and online charging data for billing purposes. Normally, the CSCF directly transfers offline charging data. When a connectivity problem occurs, offline charging data is temporarily stored before it is forwarded to an external Charging Data Function. The CSCF does not analyze the collected charging data.
- Traceability and Troubleshooting
In the CSCF, the Network Tracing, and User Tracing functions collect personal subscriber data for troubleshooting purposes. When an incident occurs, that data is analyzed to resolve it.
- User Data Output
The CSCF functionality User Data Output collects and prints user data for troubleshooting purposes. For more information about User Data Output, refer to CSCF User Data Output Guideline.
6.3.3 Personal Subscriber Data Collection and Removal
The following personal subscriber data types are collected by the CSCF:
- Semi-permanent data
This type of data is downloaded from the HSS when a subscriber registers and stored in the CSCF to enable processing of subscriber requests.
- Dynamic data
This data includes dynamic registration data and dynamic session data related to subscriber activities. Dynamic data is stored in the CSCF.
- Personal subscriber data in Event History
Event History collects and logs personal subscriber data for troubleshooting.
- Personal subscriber data in Network Tracing
Network Tracing collects and logs personal subscriber data for troubleshooting.
- Personal subscriber data during a system crash
During a crash of the system, the core dump can include personal subscriber data. Activation of the CSCF Health Check can start the collection of the core dump.
The CSCF removes semi-permanent and dynamic data when the user deregisters successfully.
Removing stored personal subscriber data can be done in the following ways, depending on the type of log or file:
- The data is overwritten at regular intervals.
- Automatic file removal is configured, see Section 6.3.4.5 File Removal.
- The operator removes the files manually, see Section 6.3.4.5 File Removal.
6.3.4 Overview of Personal Subscriber Data Handling Configuration
6.3.4.1 Role-Based Access
Role-Based Access Control can be used to limit and control the access to personal subscriber data. For more information about Role-Based Access Control, refer to User Management.
The default Role-Based access per File Management directory is described in Table 20.
|
File Management Directory |
Roles | |||||||
|---|---|---|---|---|---|---|---|---|
|
CSCFApplicationAdministrator |
CSCFApplicationOperator |
CSCFApplicationSecurityAdministrator |
Local Authentication Administrator |
Self |
System Administrator |
System Read-Only |
System Security Administrator | |
|
AlarmLogs |
RWX |
R |
R |
Deny |
Deny |
RWX |
R |
R |
|
AlertLogs |
RWX |
R |
R |
Deny |
Deny |
RWX |
R |
R |
|
BackupAndRestoreManagementFiles |
RWX |
R |
Deny |
Deny |
Deny |
Deny |
R |
Deny |
|
Cscf |
RWX |
R |
Deny |
Deny |
Deny |
Deny |
Deny |
Deny |
|
InServicePerformance |
Deny |
Deny |
Deny |
Deny |
Deny |
R |
Deny |
Deny |
|
Performance Management ReportFiles |
RWX |
R |
Deny |
Deny |
Deny |
RWX |
R |
Deny |
|
SoftwareManagement |
RWX |
R |
R |
Deny |
Deny |
RWX |
R |
Deny |
6.3.4.2 Privacy Event Logging
All privacy events, such as access to, or modification of, personal subscriber data, are logged in the audit trail log. For more information about the audit trail log, refer to Audit Information.
The syslog can be read from /var/log/messages. This is a symbolic link to the messages directory on the System Controller. For example: /var/log/SC-2-1/messages.
6.3.4.3 Data Level Minimization
The level of logged data can be reduced by setting the NetTrace trace level to minimum. For more information about setting the trace levels in NetTrace, refer to CSCF Network Tracing.
The following levels of Nettrace output types exist:
- Machine-readable at Min Level
- Machine-readable at Max Level
- Human-readable at Min Level
- Human-readable at Max Level
Specific SIP methods can also be logged. The default setting is that all SIP methods are applied.
6.3.4.4 File Access Limitation
Access to log files that contain sensitive data can be limited through Security Management rules. Refer to Handling Files for more information.
The default configuration is described in Table 21.
|
File Management Directory |
Default Policy |
|---|---|
|
AlarmLogs |
The maximum number of log files is 11. The maximum size of each alarm log file is restricted to 500 KB. |
|
AlertLogs |
The maximum number of log files is 11. The maximum size of each alert log file is restricted to 500 KB. |
|
BackupAndRestore ManagementFiles |
No default preventive maintenance policy. |
|
Cscf |
No default preventive maintenance policy. |
|
InServicePerformance |
InServicePerformance XML® report files are kept for 6 months. As a preventive maintenance policy, the system automatically cleans the old InServicePerformance reports. This activity happens once per month at the time of creation of a new InServicePerformance XML report. |
|
Performance Management ReportFiles |
The maximum number of Performance Management report files is 1000. |
|
SoftwareManagement |
No default preventive maintenance policy. |
6.3.4.5 File Removal
It is important to clean up files that are no longer needed. It is possible to clean up files automatic and manual.
To remove files automatically, follow the instructions in Configure Preventive Maintenance Policy Deleting Files in Logical File System.
To remove a file manually, follow the instructions in Delete File in Logical File System.
There is no default configuration for file removal.
6.4 Classification of Personal Subscriber Data
Table 22 lists the personal subscriber data handled by the CSCF.
|
Personal Subscriber Data Category |
Data Item |
Comments |
|---|---|---|
|
Basic data |
IP address |
|
|
IMSI |
||
|
IMEI code |
||
|
Mobile Number |
||
|
Mobile Device Serial Number |
||
|
First name |
Display Name | |
|
Last name |
Display Name | |
|
User ID |
||
|
SIP address |
||
|
Logon details |
Authentication Information | |
|
Other Basic Data |
Access-type |
|
|
Authentication information (digest, AKA) |
||
|
Public ID (IMPU) |
||
|
Private ID (IMPI) |
||
|
NoOfContacts/Contact |
||
|
Registered status |
||
|
Sensitive Data |
Call history |
|
|
Event Monitoring: event-based monitoring, call trace recordings, general performance event handling, and so on. |
||
|
Metadata showing user activity |
||
|
Content of communication: text |
Short Message | |
|
Location: LAC / CellID |
||
|
Location History |
||
|
Barred calling subscribers (Blacklist) |