Professional Documents
Culture Documents
Idoc - Pub - Huawei Cbs v500r005 Security Technical White Paper PDF
Idoc - Pub - Huawei Cbs v500r005 Security Technical White Paper PDF
Idoc - Pub - Huawei Cbs v500r005 Security Technical White Paper PDF
Issue V2.0
Date 20140831
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Website: http://www.huawei.com
Email: support@huawei.com
Fax: 0755-28560111
Contents
1 Start .................................................................................................................................................. 1
1.1 Document Scope .............................................................................................................................................. 1
1.2 Document Structure .......................................................................................................................................... 1
1.3 Usage Instruction ............................................................................................................................................. 2
1.4 CBS Solution Overview ................................................................................................................................... 2
1.4.1 Software Architecture ............................................................................................................................. 2
1.5 Security Threats................................................................................................................................................ 7
1 Start
Functional Architecture
Figure 1-1 shows the CBS's functional architecture.
Accounts Receivable
The Accounts Receivable (AR) module provides the following transaction services in a
postpaid service solution or hybrid service solution:
Single services: recharge and payment, recharge and payment reversal, refunding,
account adjustment, account transfer, payment application, write-off, and advance
deposit.
Batch services: payment application, account adjustment, advance deposit, write-off,
prepayment, and payment reversal in batches.
Query services: query for invoices, account balance, outstanding fees, payment records,
deposit details, adjustment logs, and transfer logs.
Billing Configurator
The Billing Configurator module sets the following public parameters and rules for Rating &
Charging and Invoicing:
Basic system data, such as bill cycle, network layer access data, and number analysis
data.
Rules for standard events, charging preprocessing, authentication, payment application,
and call detail record (CDR) extension.
Self-service management services.
Voice, SMS message, multimedia messaging service (MMS) message, notification,
recharge, bill run, and error CDR.
Data synchronization.
Technical Architecture
Technical Features
The technical platform of the CBS has the following features:
Distributed service framework (DSF)
In DSF, services comply with standard specifications and can be loaded and run by
containers. This framework provides the service registration, locating, routing, and
distributed access functions.
Distributed data access framework (DAF)
DAF shields both the data location and access mode differences when applications
access data.
Extensible rules
The various extensible charging rules can meet different requirements of customers on
charging policies in different charging scenarios.
Extensible service and data structure
IDE supports the flexible extension and customization of service and data structure.
Data access layer: This layer provides the distributed data access capability and shields
the data location and data source type from services. DAF, BoCache, GMDB, and PDB
are on this layer.
Table 1-1 lists the key functional modules on the technical platform.
Module Description
Module Description
IDE Extends the data model, services, and APIs.
Spoofing
Spoofing, also called identity obfuscation, is a means to hide one's true identity on the
network. A fake source address is used that does not represent the actual packet
originator's address. Spoofing can be used to hide the original source of an attack or to
work around network access control lists (ACLs) that are in place to limit host access
based on source address rules.
Session hijacking
With session hijacking, also known as man in the middle attacks, an attacker uses an
application that masquerades as either a client or a server. This results in either the server
or client being tricked into thinking that the upstream host is the legitimate host.
However, the upstream host is actually the attacker's host that is manipulating the
network so that it appears to be the desired destination. Session hijacking can be used to
obtain login information that can then be used to gain access to a system or to
confidential information.
DoS
A DoS attack is the act of denying legitimate users access to a server or services.
Network-layer DoS attacks usually tries to deny service by flooding the network with
traffic, which consumes the available bandwidth and resources.
VMs may be deployed on multiple physical machines that are placed in different physical
locations, and each VM may provide services at different security levels. If VMs are not
effectively isolated on the network or the permission to access the VM network adapter is not
managed, a user who has the remote access permission on a VM at a low security level may
launch stepping-stone attacks, which will reduce the network security.
Password Management
Password policies are configurable. Strong passwords are used to prevent password attack.
Length limitation, composition, and weak password check are applied for passwords.
Password change policies are also applied.
A strong password has the following characteristics:
Has a minimum length of eight characters.
Comprises at least one uppercase letter, one lowercase letter, and one number (special
characters are allowed).
Encryption Algorithms
The CBS uses encryption for sensitive data such as operator password, mobile user servicing
password. Account and password in configuration file used to connecting to database or other
components are encrypted before stored. Maintenance engineers cannot see plain text
passwords in databases or configurations.
Encryption algorithms for encrypt operator password and service password are configurable.
Major popular encryption algorithms such as DES, AES, MD5, SHA256 are supported and
can be chosen via configuration.
Huawei recommends that SHA256 be used to encrypt these passwords.
Security Logs
System logs security related events (such as logins, user maintenance, authorizations),
important operation events of applications, important running events, resource warning events
into log files.
These security log files are useful to audit.
Auditable Accounts
Operating systems, database, application accounts and their privilege are strictly planned in
order that management accounts are separated from operating ones; on the other hand,
operating accounts are strictly differentiated from application connect account, in order that
flexible and efficient audit strategy can be applied.
Application system can have only inherent super-user account, and common ones must be
created by maintenance. An account cannot be shared by more than one person.
Management Layer
Prevent the risks caused by system vulnerability by using appropriate policies, standards,
procedures, guidelines, patch management processes, and so on.
The administrative control for all administrators is also very important. This must
include management responsibility and "soft" controls. These controls include the
development and publication of policies, standards, procedures, and guidelines, the
screening of personnel, security awareness training, the monitoring of system activity,
and change control procedures.
Application Layer
At the application layer, the security policies and services include but are not limited to the
following:
Authorization and identification mechanism
Authentication mechanism
Cryptography
Log management
Auditing and alarm management
Data protection
SSL/TLS
System Layer
Ensure the security of applications that are based on UNIX, SUSE Linux, or Windows by
enhancing the corresponding operating system.
Use Secure Shell (SSH) and Secure File Transfer Protocol (SFTP) to prevent insecure
network traffic.
Network Layer
Separate different network traffic and control different ACLs by using appropriate
security zones that are created based on subnet division and firewall technologies.
Separate different virtual local area networks (VLANs).
Virtualization Layer
At the virtualization layer, the following methods prevent the Hypervisor from being exposed
on an insecure network and from brute force attacks and loophole attacks:
Hypervisor security hardening
VM resource isolation
Virtual network security
Security group management
Protection against DoS attacks
These security methods prevent data loss of and DoS attacks on service applications in the
virtualization environment.
are generated in special scenarios, explanation of the alarms is provided. The scanning
records (including the name and version of the scanner, version of the virus library,
scanning time, and scanning results) are archived and delivered to customers with the
software package.
An integrity verification mechanism is provided for software (including software packages
and patch packages) that is based on general operating systems. The software integrity is
verified during installation and upgrade.
Custom
er
Identity Authentication
The system provides GUIs for the login authentication and logout functions.
Strong web verification codes are used in web application account authentication and
support high-security features such as background interference and distorted characters.
For the scheme of authentication based on user name and password, the strong password
policy is forcibly used.
When a user requests a restricted resource or performs an operation requires
authentication, the user must be authenticated first. The server performs final
authentication.
After the authentication fails, the system can provide users with only the general
message instead of detailed and definite failure causes.
In B/S applications, the "automatic login/remember me" function is forbidden.
A password cannot be displayed on the GUI, printed on terminals, or stored in the logs in
plain text.
Content in the password text box cannot be copied.
A password must be saved as encrypted text rather than plain text. Irreversible
algorithms are used to encrypt passwords that do not need to be restored.
Password files must be controlled for access so that common users cannot read or copy
passwords.
A user can change the password only after being successfully authenticated.
An account list and a password list must be provided with the product.
In B/S applications, the account whose password is to be changed must be obtained from
the session information on the server and cannot be specified by the client.
A password must be different from the user name.
The default password of the built-in account must meet the password complexity
requirements. User documents must ask users to change the default password.
Authentication Failure
When the consecutive login attempts fail within the given time, the account will be
locked.
The given time segment in the policy "locking upon consecutive login failures" is
configurable
The allowed consecutive failure times in the policy "locking upon consecutive login
failures" is configurable.
The locking duration is configurable.
After the policy "locking upon consecutive login failures" is executed and the locking
times out, the system supports automatic unlocking. In addition, the system supports the
manual unlocking by the administrators.
Rights Management
The system uses the role-based account right management model.
When an account is created, no role or a role with the least rights is assigned to the
account by default.
In the B/S applications, for each URL request requiring authorization, the system must
check whether the session ID of the user is valid and whether the user is authorized to
perform the operation.
Control horizontal access to prevent users from accessing sensible data of other users
without authorization.
The authorization and user role data must be stored on the server instead of the client.
The authentication must also be performed on the server.
Session Management
In B/S applications, session cookies are used to maintain sessions.
In B/S applications, after the user name and password are successfully authenticated, the
session ID must be changed to prevent session fixation.
In B/S applications, the information that cannot be modified in a session must be stored
or maintained as a part of the session status on the server.
If a user does not perform any operations within a specified period, the system
automatically deletes the user's session. The period is configurable.
All the pages that can be accessed only after login must explicitly provide the logout (or
exit) button or menu.
In B/S applications, when a user exits, the session information about the user must be
deleted.
Security Logs
All non-query operations have log recording.
The recorded log content can support subsequent audit. Data including user ID, time,
event type, name of the accessed resource, and access result is recorded in the logs.
The log access control mechanism is provided to prevent unauthorized persons from
accessing, modifying, or deleting logs.
data contained in hidden fields, selection boxes, check boxes, option buttons,
cookies, HTTP headers, and hot spot links or client scripts. All input produced by
servers is deemed falsified and malicious by default. The validity of the input must
be verified. If the input is found invalid, data is falsified by malicious users. For
example: Assume that the Gender field is mandatory in the user information form,
use the option button (1 for male and 0 for female) to restrict the user input. If the
value of Gender received by the application is 2, someone falsifies the data
maliciously.
o It is prohibited to use any non-encrypted information in the HTTP headers as the
security decision basis. Note: The HTTP headers are sent at the beginning stage of
the HTTP request and HTTP response. The web application must not use any
non-encrypted information in HTTP headers as the security decision basis because
attackers easily operate the HTTP headers. For example, the referer field in the
HTTP header contains the URL of the web page from the requester side. Therefore,
do not make any security decision based on the referer field (for example, check
whether the request comes from the page generated by the web application) because
this field is easily falsified.
o Do not rely on the client verification. Instead, the server code must be used for final
verification of the input data. Note: The client verification is used only as an
auxiliary measure to reduce the information interactions between the client and the
server.
o Verify the input that has been verified on the client with the same rules on the server
again. Once the data is found invalid, the sessions must be made invalid and alarm
logs must be generated. Note: Attacks must exist, and the attackers bypass the input
verification on the client. Therefore, sessions must be made invalid, and alarm logs
must be generated.
o If the input can only be certain characters or character combinations, use the
whitelist for input verification. Note: For the input compliant with certain rules,
such as email address, date, and decimal fraction, use the regular expression for
whitelist verification. This method is more effective than using the blacklist for
verification.
o Verify the input data length. Note: If the input data is a string, the length of the
string must be verified. The length verification increases the difficulty of attacks.
o Verify the input data range. Note: If the input data is a numerical value, the range of
the value must be checked. For example, the age should be a positive integer
ranging from 0 to 150.
o The input parameters used for redirection cannot contain carriage returns and
linefeeds to avoid HTTP response splitting attacks. Note: A carriage return has
several expression modes (CR = %0d = \r). A linefeed also has several expression
modes (LF = %0a = \n).
PreparedStatement instead of directly executable statement is used to prevent SQL
injection for non-embedded web applications.
User data must be verified on the server. Data can be transmitted to the client after being
HTML encoded, which avoids the execution of malicious codes and cross-site script
attacks. For untrusted data, the HTML encoding is mandatory before the data is
transmitted to the client.
Code comment
o Comments cannot contain information about the physical path, database connection,
or SQL statement.
o For static pages, comments cannot contain source code information.
o For dynamic pages, common comments are not used, and only hidden comments are
used.
When the application is abnormal, capture the exception, filter the information and return
only the common error messages to the client (do not disclose unnecessary information
to the client), and record the detailed error information in the log.
The whitelist must be used on the server to strictly restrict the types of uploaded or
downloaded files.
The CBS provides privacy protection schemes so that carriers can meet local laws and
regulations and customer requirements on privacy protection.
o Data collection
To enable subscribers to use services and receive system notifications, the CBS collects
individual data based on service information. Carriers and subscribers must sign the data
collection contract so that the system can process subscriber data to generate production
data required by the service system. Without being authorized by subscribers, the CBS
does not collect, store, or process subscriber data.
Registration
During registration, the system collects service-related data including the customer's
name, certificate number, date of birth, phone number, password for query, home address,
email address, and invoice address. The system does not collect service-irrelevant
information, such as, family members and their health status. In the self-registration and
self-service scenarios, the system displays the data collection purpose and notifies the
subscriber of data to be collected. When connecting to a third-party system interface, the
CBS notifies the interface of the mandatory and optional data to be collected.
o Deregistration
The CBS starts a scheduled task to automatically clear all individual data X days after
deregistration.
o CDR
CDRs record the calling number, called number, communication time, location
information, and other information. The CBS can store CDR files without importing
them to a database or start a scheduled task to automatically clear CDR files a specified
time period after they are stored. The CBS does not import the location and peer number
in CDRs to the database.
NEs in the CBS use SFTP to transfer CDR files. Permission on the files is set as follows:
The owner has read, write, and delete permission, and users in the same group as the
owner has the read permission. Other non-root users have no permission on CDR files.
The CBS records an operation log each time a CDR file is queried.
CDR files in the CBS are used by the Invoicing to accumulate accounts, used by the
report system to collect and analyze statistics, used by the RA to audit and rerate CDRs,
used by the GL for accounting, and used by a third-party system (for example, PRM) to
execute settlement.
o Invoice
Invoices record the customer name, invoice address, calling number, called number,
consumption information, balance, total outstanding amount, and other information. The
information can be customized by carriers, and called numbers are anonymized.
o Receipt
Receipts record information such as the customer name and phone number.
Receipts are compressed before being stored in a database.
The recharge and payment log table records information related to the bank account,
such as, the credit card number, card expiration time, credit card authorization code,
bank account, check number, and check data.
The CBS deducts fees based on the information related to the bank account. Therefore,
the system uses the reversible algorithm AES128 to encrypt and decrypt the information
and then stores it in the database.
o Encrypted storage
The system encrypts sensitive data such as the password, bank account, cipher key, PIN1,
PIN2, PUK1, and PUK2 so that the sensitive data is not displayed in plaintext.
The system uses the irreversible algorithm Hmac-SHA256 to encrypt the login password.
The user name is used as the salt for password encryption, which ensures that different
ciphertexts are obtained for the same password. The ciphertext is stored in the CBS
database and is used for verifying the login password that a subscriber enters.
The system uses AES128 to encrypt and decrypt the authentication passwords transferred
between the client and server. The two ends use the same algorithm and cipher key to
ensure that the peer end can decrypt the received passwords. The passwords are
generally stored in configuration files in ciphertext for applications to query. Cipher keys
are generally stored in configuration files in ciphertext to protect key security.
The system generally uses AES128 to encrypt and decrypt bank accounts.
o Encrypted transmission
o Data display
Sensitive data is not displayed on web pages, log files, and configuration files in
plaintext. To protect the security of sensitive data such as bank accounts, the system
saves the data in the database in ciphertext, displays the first six or last four digits of
each record on web pages for tracing services or transactions, and displays the
encryption status in log files. If the system does not displays the encryption status in log
files, it displays the first six or last four digits and uses asterisks (*) to mask other digits.
Passwords are masked with asterisks (*) on web pages or text boxes and recorded in
ciphertext in log files and configuration files. Cipher keys are displayed in ciphertext in
configuration files.
Other sensitive data such as PIN1, PIN2, PUK1, and PUK2 is displayed in ciphertext.
Individual data of subscribers such as their names, phone numbers, invoices, and
transaction data is displayed in plaintext on web pages and log files. However, individual
data exported to other systems out of the production system or imported to the
development and test system is anonymized. That is, the system performs transcoding for
individual data such as the name and mobile number to protect subscribers' privacy.
Service-related data is backed up based on a backup policy. The backup scope, time, and
interval can be configured in the backup policy. Generally, data generated within a
specified time period is backed up as online backup data for fast restore. By default, the
CBS stores data backed up in the last month as online backup data on disks and stores
data backed up earlier as offline backup data.
Data restore tests must be performed on a regular basis to test the validity of the backup
policy and backup data.
deployed. The management network can be connected only through this zone to
manage system networks.
o DMZ: The security level is 50. Applications (such as the BMP Gateway, EVC
Portal, and SLB) that directly interact with Internet users are deployed to
implement the Internet access and request distribution.
o OIT: The security level is 55. The LBI is deployed and is provided only for
customers' system administrators. The administrators can use the system
reconciliation and report audit functions.
o HA: The security level is 60. The connection heartbeat interfaces for firewalls are
deployed.
o TEST: The security level is 80. NEs for test, training, and environment
development are deployed.
o Trust: The security level is 85. Service NEs including the CBP, BMP, EVC, UVC,
and UAP are deployed to implement core system functions such as charging,
recharge, and service management.
o OM: The security level is 90. The management plane (including network
management systems, management ports of hardware devices, and service
management plane) is located in the OM zone. To access and control the
management plane, an external network management center needs to connect to the
OM zone of the firewall.
The management plane is a common plane that involves NEs in various security zones.
Security isolation must be implemented in the management plane to prevent NEs in various
security zones from connecting to each other in the management plane.
In addition, maintenance engineers are advised to use the VPN to connect to core services and
boundary firewalls of the data domain during remote maintenance. The VPN service can be
enabled in the firewalls. The VPN type is IPSec VPN. The VPN client IP address pool can be
configured in the firewalls, and the VPN service assigns IP addresses to maintenance
engineers' clients. Also, filter policies are configured in the firewalls to enable only IP
addresses in the VPN client IP address pool to connect to servers through the firewalls.
3 Security Assurance
Business plan
charter PCR IPD
MM
charter Concept Plan Development Qualify Launch Lifecycle
OR: offering requirement IPMT: Integrated Portfolio Management Team EOS: end of support and service
MM: market management PDT: Product Development Team BBFV: build block functional verification
IPD: integrated product development DCP: decision checkpoint SIT: system integrated test
PCR: product change request TR: technical review SVT: system verification test
CBB: common building block EOM: end of marketing GA: general availability
PKI: Public Key Infrastructure EOP: end of production UCD: user centered design
C
CBS convergent billing system
CSRF cross-site request forgery
E
E2E end-to-end
F
FTP File Transfer Protocol
H
HTTP Hypertext Transport Protocol
HTTPS Secure HTTP
N
NFS Network File System
NTP Network Time Protocol
O
OSI open systems interconnection
Q
QoS Quality of Service
R
RBAC Role-Based Access Control
S
SNMP Simple Network Management
Protocol
SSH Secure Shell
T