Managing BRM Security

The Security Model

BRM security requirements arise from the need to protect data: first, from accidental loss and corruption, and second, from deliberate unauthorized attempts to access or alter that data. Secondary concerns include protecting against undue delays in accessing or using data or even against interference to the point of denial of service. The global costs of such security breaches run up to billions of dollars annually, and the cost to individual companies can be severe, sometimes catastrophic.

The critical security features that provide these protections are:

Authentication: Ensures that only authorized individuals get access to the system and data.
Authorization: Ensures access control to system privileges and data. Authorization builds on authentication to ensure that individuals get only appropriate access.
Audit: Allows administrators to detect attempted breaches of the authentication mechanism and attempted or successful breaches of access control.
Encryption: Ensures that data cannot be read without being adequately decrypted.

BRM enables TLS by default to secure communication between applications. See "Enabling Secure Communication between BRM Components" in BRM System Administrator's Guide for more information.

Configuring and Using Authentication

BRM requires two levels of authentication within its operation:

Both levels of authentication use Oracle Wallet.

By default, the BRM installer stores configuration entries, including sensitive information (such as TLS certificates and database and account passwords), in the Oracle wallet. BRM applications retrieve the data from the Oracle wallet unless the configuration entries are also stored in the Infranet.properties and pin.conf configuration files. The entries in the configuration files take precedence.

Authentication of Applications

Each component in the application tier must authenticate itself against an account to be allowed to send requests to the BRM server. The user name is stored in the application's configuration file. By default, the password is stored in the Oracle wallet, but the application may be configured so that the password is encrypted using AES and stored in the application's configuration file.

Application account information is stored in the BRM database. All passwords are hashed and encrypted before being stored in the database. When the application connects, the password is hashed and the hash is compared with the hashed password in the database.

Authentication of Accounts

Users requesting permission to carry out a transaction must be authenticated against the account information stored in the BRM database. All passwords are hashed and encrypted before being stored in the database. The user name and password are typed in by the user, and then the password is hashed and the hash is compared with the hashed password in the database.

Configuring and Using Access Control

Configure and use access control in BRM.

Permissions

Permissions determine which tasks a user can perform with BRM applications.

It is possible to restrict activities in applications, such as Customer Center and Pricing Center, by assigning CSRs to a role and setting permissions for that role. For example, it is possible to specify which CSRs can change a password, apply credits, and give refunds. See "Setting Up Permissions in BRM Applications" in BRM System Administrator's Guide for more information.

In most cases, only a person with root access, such as a system administrator, is granted permission to change CSR permissions.

See "Managing ECE Permissions" in BRM System Administrator's Guide for more information.

Roles

A set of permissions defines a role. A role represents a set of actions that a person holding a particular job or position can perform. Roles are used to configure permissions for a group of CSRs based on the tasks they need to perform. For example, it is possible to create different types of CSRs and assign them to different kinds of roles:

Manager CSRs can create new roles, assign CSRs to roles, change permission settings, change credit limits, give refunds, and change account status. A manager can also validate the work that junior CSRs perform, for example, by making sure that new accounts are created correctly and have all the necessary information.
Junior CSRs can check customer account balances, check and change billing information, and answer common customer questions.

For example, CSRs A and B can be assigned to the role Manager, and CSRs C and D can be assigned to the role Lead-CSR, where:

CSRs A and B have read-write permissions for customer credit card information.
CSRs C and D have read-only permissions for customer credit card information.

It is also possible to create roles with higher levels of permissions. For example, you can create roles that include permissions to create and manage roles using Permissioning Center.

Roles can also be set up to access one or more client applications. In addition, a CSR can be assigned to multiple roles. For example, a CSR can be assigned to a Manager role in Permissioning Center and to a Junior-CSR role in Pricing Center.

Roles can be hierarchical, by creating child roles and associating them with a parent role. At each level above the bottom of the hierarchy, the child roles can also be parent roles. A child role inherits all permission settings that are associated with its parent role.

See "About Managing Roles" in BRM System Administrator's Guide for more information.

Managing CSR Passwords

To improve security features and provide access to BRM client applications, the following password policies are included in Permissioning Center:

Ability to set password expiry limits: The duration of time that a password is valid until the system prevents a user from logging in or forces the password to be changed.
Ability to define temporary passwords: The ability to force CSRs to change their passwords after accessing the application the first time or after a new CSR account has been set up by an administrator.
Password content validation: The ability to validate the contents of the password to make sure that certain characters are or are not included, such as numbers.

See "Managing CSR Passwords" in BRM System Administrator's Guide for more information.

Account Lockout

Users are locked out of the system after a specified number of invalid login attempts. See "Configuring the Maximum Number of Invalid Login Attempts" in BRM System Administrator's Guide for instructions for changing the default number of attempts allowed.

Once users are locked out of the system, manual intervention is required to reenable the accounts. See "Unlocking a Locked CSR Account" in BRM System Administrator's Guide for instructions for unlocking the accounts.

Automatic Logout

BRM provides the functionality to force a user to reauthenticate after a given amount of idle time. However, if the password is present in the configuration file, the authentication is automated. This facility should not be used to allow automated reauthentication of CSR accounts.

You can configure the interval for the session to time out by setting the cm_timeout parameter. See "Setting the CM Time Interval between Opcode Requests" in BRM System Administrator's Guide for detailed instructions.

Access Control in BRM Web Services Manager

BRM Web Services Manager enables BRM opcodes to be exposed through Web services.

You can use access control capabilities to restrict Web services to certain user roles. Multiple roles can be created, each with a different set of privileges. You define access restrictions for Web services in security policies in WebLogic Server. See "Configuring WebLogic Security Policy on BRM Web Services for JAX-WS in WebLogic Server" in BRM Web Services Manager for more information.

Web Services Manager uses the OAuth 2.0 protocol to authenticate a client application's identity and to authorize the client application to access BRM Web services. See "Securing Web Services Manager with OAuth2" in BRM Web Services Manager for more information.

Configuring and Using Security Audit

BRM provides support for auditing any object in the BRM database so that a record is kept of every version of the object for future reference. This can be used to track changes to customer profiles, customer payment information, and so on. An audit trail can also be used to track internal changes, such as changes to your pricing components.

Specific fields within objects can be requested to be audited. However, because there is a performance overhead, auditing should be switched on only for those fields where there is felt to be a security risk.

Encryption

By default, BRM encrypts the passwords stored in the BRM database.

However, this can be extended to encrypt fields that contain sensitive customer information, such as credit card numbers, to guarantee privacy and prevent unauthorized use. The fields to be encrypted must be in string format. You set up encryption with the BRM Storable Class Editor, which will add a flag attribute in the meta-data defining the field in the BRM data dictionary (PIN_FLD_ENCRYPTABLE).

BRM encrypts the fields marked for encryption when storing them in the database and automatically decrypts the fields when retrieving them from the database.

See "About Encrypting Data" in BRM System Administrator's Guide for more information.

Using Oracle ZT Encryption Scheme

Each instance of BRM has a unique root encryption key. This root key is used for all encryption/decryption processes in BRM. You can use an instance-specific root encryption key to assign different keys for development, test, pre-production, and production instances of BRM.

When different root keys are used for each instance, the sensitive subscriber data and other credentials, such as subscriber passwords, cannot be copied from one instance to another and decrypted in the other system.

The encryption scheme adds a random initial vector for each plain block of text to be encrypted. This prevents pattern-based attacks.

See "Generating a Root Encryption Key" in BRM Developer's Guide for more information.

Securing Sensitive Customer Data

Protect subscriber data by masking values contained in system responses to clients and logging.

See "Masking Sensitive Customer Data" in BRM Managing Customers.

Using Credit Card Tokenization

Credit card tokenization is a secure method of storing credit and debit card data. It replaces the credit and debit card numbers with random identifiers, referred to as tokens. You can use tokens for any BRM-initiated payments instead of the actual card numbers. The actual card numbers and their mapping to the tokens are stored securely in Paymentech. Tokens are valid only between the merchant system and the credit card processor. You can use tokens to transmit safely without the risk of exposing credit or debit card data.

See "Masking Credit Card Numbers by Using Tokens" in BRM Configuring and Collecting Payments for more information.

You can migrate previously stored credit card numbers to tokens by using the provided migration application. See "Replacing Credit Card Numbers with Tokens" in BRM Configuring and Collecting Payments for more information.

You can use tokens generated outside BRM for credit and debit cards by sending the token into the application in the PCM_OP_CUST_COMMIT_CUSTOMER opcode. See BRM Opcode Flist Reference for more information about PCM_OP_CUST_COMMIT_CUSTOMER.

You can prevent users from entering any credit card information in Billing Care by removing the creditCard entry from the paymentTypes key in the Billing Care CustomConfigurations.xml file. See "Editing the Billing Care Configuration File" in Billing Care SDK Guide for more information about the CustomConfigurations.xml file.

Masking Sensitive Data in Log Files

BRM comes preconfigured to store sensitive data in an encrypted format. However, because encryption and decryption are done in the Data Manager to ensure that the business logic has access to the real value, these fields should also be marked as masked so that their values do not appear in any of the BRM log files.

See "Defining Masked Fields" in BRM Developer's Guide for more information.

Securing BRM Network Ports

The BRM PCM protocol cannot enforce access control to any of the command line applications or other custom C or Java applications. Therefore, operating system and network security measures must be used to secure access to the BRM network ports:

Enable TLS to secure the BRM PCM communications. See "Enabling SSL/TLS for C and C++ PCM Clients" and "Enabling SSL/TLS for Java PCM Clients", both in BRM System Administrator's Guide, for more information.
The Connection Manager (CM) port must be blocked to prevent any connections from any desktops that do not have a business justification to run any BRM client application.
BRM DM port: The BRM DM port must be blocked to prevent any connections other than from servers that are running an instance of the CM that is to be allowed access to the DM.

About Managing ECE Security

To manage ECE security, you perform the following tasks:

Set up user accounts and user groups, and grant permissions. After creating user groups and setting permissions, users can log in to the system, use ECE, and manage the ECE cluster.

You can assign permissions for users who run and manage ECE processes, manage rated event files, and manage the ECE file systems. Restrict permissions as much as possible. You can create either a single administrative user with all permissions who runs ECE core processes and manages the rated event files and other directories, or create multiple users with specific permissions to carry out these tasks.

See "Configuring Specific File Permissions" in BRM System Administrator's Guide for a list of the files that you need to restrict access to.
Manage passwords. Linux accounts protected by passwords must be created for ECC. Besides the Linux accounts, you need to create non-Linux accounts to access external applications like Oracle Communications Billing and Revenue Management (BRM) and Oracle Communications Pricing Design Center (PDC). BRM and PDC are used to load customer and pricing data respectively into ECE. For secure communication between ECE and these systems, credentials stored in ECE are encrypted and stored in the KeyStore.
Set up cluster security. To restrict access to the ECE Coherence cluster, you must set up an authorized hosts list. You can optionally enable SSL for intra-cluster communication, in which case you must also enable Well Known Addresses (WKA).
Set up passwordless Secure Shell SSH between driver and server machines. You must set up passwordless SSH between driver and server machines for ECC to work. Passwordless SSH allows servers to connect to the driver and synchronize ECE files.

5 Managing BRM Security