This chapter describes how to manage security in Oracle Communications Billing and Revenue Management (BRM).
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: Ensuring that only authorized individuals get access to the system and data.
Authorization: Access control to system privileges and data. This 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 properly decrypted.
BRM requires two levels of authentication within its operation:
Each component in the BRM Application tier must authenticate itself against an account to be allowed to send requests to the BRM server. The user name and password for this account are kept in the application's configuration file. By default, the password is encrypted using AES and stored.
The account authenticated against is held in the BRM database. As a result, the mechanics of the authentication are identical to that of the authenticating an account.
Users requesting permission to carry out a transaction must be authenticated against the account in the BRM database. All passwords are encrypted and stored in the BRM database.
Configure and use access control in BRM.
Permissions determine which tasks a user can perform with BRM applications.
It is possible to restrict activities in Customer Center, Pricing Center, and other applications 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.
Permissions can be set up using both Permissioning Center and Customer Center. However, the user adding, changing, or deleting permissions must have the correct permissions to do so. In most cases, only a person with root access, such as a system administrator, is granted permission to change CSR permissions.
See "Setting Up Permissions in BRM Applications" in BRM System Administrator's Guide for more information.
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 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.
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.
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.
See "Automatic Logout" in BRM System Administrator's Guide for more information.
BRM Web Services Manager enables BRM opcodes to be exposed through Web services. Web Services Manager uses the Apache Axis framework to support SOAP 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.
See "Configuring Security for Web Services Manager" in BRM Web Services Manager for more information.
BRM provides support for auditing any object class 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 price list.
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.
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 Storable Class Editor, which will add a flag attribute in the metadata 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 Information" in BRM Developer's Guide for more information.
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 "Configuring the Data Manager for Oracle ZT PKI Encryption" in BRM Developer's Guide for more information.
Protect subscriber data by masking values contained in system responses to clients and logging.
See "About Securing Sensitive Customer Data with Masking" in BRM Managing Customers for more information on setting up data masking.
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 the credit or debit card data.
See "About Replacing Credit Card Numbers with Tokens" in BRM Configuring and Collecting Payments for more information.
Customers upgrading to BRM 7.5 Patch Set 10 or later may migrate previously stored credit card numbers to tokens by using the provided migration application.
See "About Migrating Credit Card Information from Legacy Databases" in BRM Configuring and Collecting Payments for more information.
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.
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:
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.