ert82017 Document 7383444 White Paper - Payment Applications Best Practices (Doc ID 738344.1) This white paper describes the Payment Applications Best Practices (PABP) functionality in Payments. It should be read by any customer, integrator, or reseller implementing credit card processing within the Oracle eBusiness Suite. Create Date: 09-September-2008 Overview Overview of Payment Application Best Practices Payment applications, when implemented into a complete Payment Application Best Practices (PABP)-compliant environment {and according to the information in this White Paper, facilitate and support a retailer in their Payment Card Industry Data ‘Security Standard (PCI-DSS) initiatives. This topic provides an overview of the security features of Oracle Payments applications, Oracle Payments conforms to all applicable PABP requirements allowing implementers to achieve compliance with Payment. Card Industry (PCI) Data Security Standards (DSS). Sensitive Data Incidence Payments provides secure payment instrument storage and funds capture pracessing functionality for the entire Oracle eBusiness Suite. The following matrix ists all PABP-incidental data and the extent of Oracle Payments's interaction with it: Externally Data Type [Stored _|Processed| Presented | Transmitted (Credit card primary account number x x x (PAN) (Credit card validation code x |X (Only for x R12) Payment instrument magnetic track data External system access information (e.9.| — X x x x x login passwords) Key-encryption cryptographic key x Data-encryption cryptographic key x x x Where: ‘+ Received represents an entry-point for data. It is accepted as a parameter of an API or functional process and only retained in volatile storage such as computer memory. + Stored indicates permanent storage such as the database or a file system. + Processed is accessed internally by Oracle Payments in a plain-text (decrypted) format but not communicated outside the processing module. hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 aneer182017 Document 7383444 ‘+ Presented represents plain-text of the data presented through an electronic form; and not in a truncated or masked form, ‘+ Externally Transmitted represents delivery of data to an external system, typically through electronic network communication. Data Flow The following diagram illustrates the flow of PABP-incidental data between the applications of Oracle eBusiness Suite and within the internal modules of the Oracle Payments application. Front End API These APIS provide the PL/SQL interface to Payments payment instrument repository and funds capture payment processing functionality and are the primary interface to Payments for the rest of the Oracle eBusiness Suite. These APIs perform minimal processing and have no persistence to sensitive data, and delegate process execution to the Payments middle-tier Java engine through an HTTP call-out. This module's interaction with PABP-incidental data is as follows: Externally Data Type Received |Stored | Processed | Presented | Transmitted Credit card primary account number (PAN) | xX x Credit card validation code x x Payment instrument magnetic track data External system access information (for example, login passwords Key encryption cryptographic key Data encryption cryptographic key + Received = The PL/SQL API accepts plain-text primary account number and card security validation code data + Externally Transmitted = This module sends its parameter data to a serviet on the middle-tier for final processing of a request; instructions for securing this network link are given in the Installation section Payment Engine/Back End APT The Payments engine receives PABP-incidental data either directly or through its PL/SQL adapter ECServiet interface, and ultimately transmits it to an external payment system for final processing [Externally Data Type Received | Stored | Processed | Presented | Transmitted Credit card primary account number (PAN) | __X x x (Credit card validation code x x x Payment instrument magnetic track data External system access information (€.9. x x x login passwords) Key-encryption cryptographic key x x x Data-encryption cryptographic key x “+ Received indicates that the Engine receives the clear-text of PABP-incidental data either in memory from another co- located eBusiness Suite application or remotely through its EC Application serviet interface. ‘+ Processed indicates that the engine decrypts sensitive data during the process of creating and transmitting payment instructions, This includes payment instrument data along with remote payment system access information such as hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -siako=huts3eb_S78id= 7389481 oner182017 Document 7383444 account names and passwords. + Externally Transmitted indicates that payment request message contains payment instrument and remote account access data sent either directly to a remote payment system or a Payments back-end payment system servet. Engine PL/SQL. The set of PL/SQL methods invoked through JDBC by the Java middle-tier engine to perform both data storage encryption as well as data decryption, Externally Data Type Received |Stored | Processed | Presented Credit card primary account number (PAN) | _X x x (Credit card validation code x x x Payment instrument magnetic track data External system access information (e.g x x x login passwords) Key encryption cryptographic key x Data encryption cryptographic key x x x ‘+ Received indicates that the Engine PL/SQL accepts plain-text primary account number and card security validation code data as well as remote system access data; it also receives key-encryption (master key) data whenever the master key is created or changed; this data is transmitted through Oracle SQL*Net between the middle-tier to the database host, servers + Stored stores PABP-incidental data in Oracle Applications database tables in both encrypted and digested (hashed) formats. ‘+ Processed decrypts PABP-incidental data during generation of payment instruction requests as well as key rotation activities. + Externally Transmitted sends the payment systems servlet module a data encryption key for encryption payment system acknowledgment files; this key is transmitted over HTTP. Payment System Serviet ‘The payment system servlet delivers a funds capture payment instruction to the back-end payment system. This instruction, representing either an authorization or batch of settlements, containa one ore more instances of primary account number and ‘ard validation code data. The interaction is as follows: Externally Data Type Received | Stored | Processed | Presented | Transmitted Credit card primary account number (PAN) | _X x x (Credit card validation code x x x Payment instrument magnetic track data External system access information (e.g x x x login passwords) Key encryption cryptographic key Data encryption cryptographic key x ‘+ Received indicates that the Serviet receives clear-text payment instrument and remote account access data over a HTTP network link as well as a data encryption key to encrypt acknowledgements, + Stored indicates that the Servlet archives the payment system response acknowledgment in a local directory to prevent duplicate transactions should the request be retried by the engine after system failure of the initial request; this hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 aneer182017 Document 7383444 acknowledgement contains echoed payment instrument data and so is encrypted before being put to fil. ‘+ Externally Transmitted represents the payment instruction data containing primary account number and card validation code data is transmitted to the external payment system. The access credentials to the payment system itself are also transmitted using an insecure protocol (for example, FTP) though typically only over a controlled network link (that is, leased line connection). Scheduler Payments uses the concurrent program processing server to perform both funds capture offline transaction processing as well as security architecture maintenance routines such as key rotation and historical data upgrade (encryption). Externally Data Type Received | Stored | Processed | Presented | Transmitted (Credit card primary account number (PAN) x x (Credit card validation code x x Payment instrument magnetic track data External system access information (e.g x x login passwords) Key-encryption cryptographic key X (Only for R12) Data-encryption cryptographic key x x “+ Processed indicates that the concurrent program tier decrypts sensitive data during the process of creating and transmitting payment instructions. Tt includes payment instrument data along with remote payment system access information such as account names and passwords. + Externally Transmitted indicates that the payment request message containing payment instrument and remote account access data sent elther directly to a remote payment system or a Payments back-end payment system servet. Security Architecture The Payments security architecture secures PABP-incidental data using a chain key approach. The chain key consists of a site~ wide key-encryption key (master key or system key) that encrypts one or more data-encryption keys (subkeys), each of which is used to encrypt a fixed amount of data before a new data-enicryption subkey is generated. This approach ensures quicker rotation of the system key. The architecture is comprised of the following components: + Payments System Key + Oracle Wallet (Available only in Oracle Applications Release 12) + FND Vault (Available only in Oracle Applications Release 11/) + FND Vault Key (Available only in Oracle Applications Release 11i) + Payments System Subkeys + Secure Segments Storage Payments System Key When you enable encryption in Payments, you create one system-level security key, which is a password comprised of a maximum of 24-characters. The system key is the key-encryption master key for the entire installation, Ttis stored in the FND_VAULT database [in R12 the Oracle Wallet] and is used to encrypt the Payments data-encryption subkeys, The system key can be rotated, which changes the subkey data, but does not result in a re-encryption of secured data (for example, credit card numbers) itself. tions Release 111) The FND Vault is an Oracle Applications program module that protects stored data in an encrypted format. The Payments system key is automatically stored in the FND Vault module. hips:iisupportcacle.comlepmesfacesiDocumentDisply’? ae. -sako=huSts3eb_S7Bid= 738948 1 anger182017 Document 7383444 FND Vault Key (Available only in Oracle Applications Release 111) The FND Vault key is a random, system-generated password used to secure everything stored in the FND Vault. The FND Vault key can be rotated, which results in re-encrypting all the data stored within it, Payments Subkeys Payments subkeys are randomly system-generated symmetric-cipher keys that are encrypted using the system-level Payments ‘Security Key. The system does not store the Payments subkeys in unencrypted format. Payments subkeys are used to encrypt PABP-incidental data such as credit card primary account numbers, The system manages the creation and encryption of Payments subkeys automatically The use of subkeys in the encryption solution allows you to perform a quick rotation of the system master key. Rotating the master key re-encrypts only the Payments subkeys, rather than the data they are responsible for. For the default setting, a Payments subkey secures one thousand rows of data. Secure Segments Storage Encrypted data are stored in the Payments IBY_SECURITY_SEGMENTS table. Credit card primary account numbers are stored in this table regardless of the source application (for example, Order Management, iStore, or others) that captured that credit card number. Sensitive data is stored in a separate table in case you need to apply additional security measures to the data based on your internal policy. For example, the system administrator may choose to store the database files that contain the encrypted data in a special file system directory. To do so, you can relocate the IBY_SECURITY_SEGMENTS table to a separate database and create a synonym in the local database that points to the remote table. Such a configuration is not required for a PABP- compliant installation. Infrastructure Network Topology Payments is implemented across the following tiers of the Oracle Applications architecture: + Database Tier + Application Tier Within the Applications Tier, Payments executes on the following services group nodes: + Web Services + Concurrent Processing server (optional) ‘Communication can occur between each tier and in either direction depending on which features of Payments are implemented. Communication always occurs from the Application Tier to the Database Tier, and can occur from the Database Tier to the Application Tier, if Payments PL/SQL APIS are invoked, Most Oracle eBusiness Suite applications integrate with Payments through these PL/SQL APIS. Payments back-end payment serviets require communication with Third party banks and payment processors over open networks such as the Internet. The out-of-the-box payment systems integrations requiring such open-network connectivity are: + Cybercash + Concord EFSNet The following out-of-the-box payment system integrations communicate with their destination payment systems over non-open networks (for example, leased line): + First Data North + Paymentech PABP Requirement 9 (listed later in the White Paper) states that cardholder data cannot be stored on an internet-connected server. The Database Tier must be deployed to internal network nodes. Additionally itis recommended that the Application hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 seer182017 Document 7383444 Tier and all its constituent services be deployed on internal network nodes and any open network-communicating payment. system servlets be deployed on special Web Services nodes separated from the rest of the Application Tier by a firewall Wireless Oracle Applications allows, but does not require, the use of wireless network technology, Using wireless communication links in your Applications deployment, even on internal-network nodes, activates several additional PABP requirements, in particular PABP Requirement 12 and all or Requirement 9 (are listed later in the White Paper). Encrypt wireless transmissions by using WiFi Protected Access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS. Tt is recommended that you do not rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN. If WEP is used, then ensure the following: + Use with @ minimum 104-bit encryption key and 24 bit-initilization value. + Use ONLY in conjunction with WiFi Protected Access (WPA or WPA2) technology, VPN, or SSL/TLS + Rotate shared WEP keys quarterly (or automatically ifthe technology permits) + Rotate shared WEP keys when a personnel changes with access to keys ‘+ Restrict access based on Media Access Code (MAC) address Install personal firewall software on any mobile and employee-owned computers with direct connectivity to the Internet (for ‘example, employee laptops) and access to your internal network. Install perimeter firewalls between any wireless networks and your internal network and configue these firewalls to deny any traffic from the wireless environment or from controlling any traffic (if such traffic is necessary for business purposes), Also ensure the following: ‘= Change the WEP keys from their instal-time defaults (and anytime an individual with knowledge of the keys leaves the company or changes positions) + Chane the default SSID + Disable broadcast of the SSID + Changed default SNMP community strings on access points + Change the default passwords on access points ‘+ WPA or WPA2 technology is enabled if the wireless system is WPA-capable + Change other security-related wireless vendor, if applicable Installation Payments 111 Prerequisites Apply the following prerequisite patches: Bug Required for Required for Number |Description Release 11.0.9 _|Release 11.0,10 115.10 ORACLE E-BUSINESS SUITE x CONSOLIDATED UPDATE ? Patch | 111.1EX.H Yes Yes 3999182 Patch | 11.FIN_PF.G. Yes Yes 3653484 Patch | 111.0KLG Yes Yes 3981693 Patch | 11i,.MAS_PFA Yes No 3386886 hips:supportcace.comlepmesfacesiDecumentDisplay’?_ ae. -siato=kuSts3eb_S78id= 738948 1 aneer182017 Doocumens 7383444 Bug Required for Required for Number |Description Release 11.0.9 _|Release 11.0.10 Patch | 111,SCM_PF.J Yes No 3384350 Patch |11.5.10 Marketing and Sales Family Pack [Yes N 4249280 _|Rollup 2 Post-install Steps After you have successfully applied all of the patches, you must complete these steps. If you completed a task during a previous patch application, then you do not need to complete the step again, unless otherwise specified. Review the Latest Applications Recommended Patch List Refer to the latest 111 or R12 Applications Recommended Patch List to see if you should apply any additional Oracle iPayment patches on top of Oracle Applications PABP. To access the Applications Recommended Patch List: 1. Log on to Oracle MetaLink 2, On the Oracle MetaLink page, click Patches. 3, Click the eBusiness Suite Recommended Patch List link 4, Specify your query criteria to retrieve application recommended patches for your instance, Review Credit Card Encryption Exceptions List Reports ‘The Oracle Applications Credit Card Encryption patch does not encrypt credit card numbers that are greater than 30 characters. Any instances of such credit card data are invalid. Before you enable encryption and upgrade historical credit card data, itis recommended that you check for any invalid data and correct it. This patch provides a set of reports that can be run to list exceptions. If the upgrade programs are executed before fixing the invalid credit card numbers, the upgrade programs encrypt the valid numbers and leave the invalid ones unencrypted. Run the following reports and review: Product Report Oracle Payables List AP Credit Card Encryption Exceptions (Oracle Order Capture List ASO Credit Card Encryption Exceptions Oracle Order Management List OM Credit Card Encryption Exceptions Oracle Service Contracts List OKS Credit Card Encryption Exceptions Enable Encryption After applying the patch, itis recommended that you enable encryption. Otherwise, you will create adaitional unencrypted credit card data that must be upgraded. For current Oracle Payments users, applying the encryption patch automatically disables the previous encryption feature. Attention: Once you enable credit card encryption, you cannot disable this functionality. Read this guide thoroughly and Understand all implications of enabling the encryption feature before proceeding, Enabling the Credit Card Encryption feature is done in the Oracle Payments product. To enable the feature, perform the following steps: hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 meer182017 Document 7383444 1. Assign the iPayment Payment Administrator responsibility to the user who will perform the setup. 2, Select the iPayment Payment Administrator responsibility 3, From the Navigator, select System Security Management, 4, Before you enable encryption, create your security key, Click Create Key. 5, Enter your security key information and apply the changes. Note: + Itis recommended that you use a randomly-generated system key, Oracle Payments can generate a random system key for you or else read one from a flatfile you provide, + For 11i Payments Credit Card Encryption users from release 111,IBY.Q, use the single unified key that you created, 6. Set the Encryption Enabled setting to Yes. 7. Click Apply to complete the setup. Upgrade Historical Data To migrate existing credit card data to the new encrypted security model, a set of concurrent programs must be run. Attention: You must run the historical data upgrade programs even if you have previously dane so before as the additional card holder data is being encrypted to meet PABP requirements. To simplify the upgrade process, these programs are bundled into a single request set named Encrypt Historical Card Data. When this request set is submitted, it launches separate upgrade programs for each product that stores credit card information in its data model, The following table lists the programs that are run as part of this request set. Product Report Oracle Payables Encrypt AP Historical Card Data (Oracle Order Capture Encrypt ASO Historical Card Data (Oracle Order Management Encrypt OM Historical Card Data (Oracle Service Contracts Encrypt OKS Historical Card Data Oracle Payments Encrypt IBY Historical Card Data Oracle Payments [Sweep Historical XML Card Data Monitor these programs to ensure that they complete successfully. If necessary, run all the programs. The upgrade programs do not have to be run during downtime. The request set can be submitted and the programs can run in the background during regular business operations. These programs encrypt all existing credit card data in your installation Depending on the volume of credit card data that you store, these programs may take a long time to run. If you are scheduling a regular downtime for any other reason, you may want to consider running this upgrade request set at the same time to improve performance. If you are currently using the Oracle iPayment Risk Management feature, then run your historical data upgrade first. Otherwise, your risk formulas may fail. Ifthe data upgrade has not been completed, any risk formulas that use the following factors return incorrect results: + Frequency of purchase + Payment history + Transaction amount hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 aneer182017 Document 7383444 Configuration Operating System Please ensure that for each host in your deployment, the operating system configuraiton meets PABP account and password standards as defined in PABP Requirement 3. Also ensure that any unnecessary services or insecure protocols are turned off con all such machines per PABP Requirements 5.4. Examples of such services and protocols are: NetBIOS, file-sharing, Telnet, unencrypted FTP. If remote access Is required to such hosts ensure that itis done through secure protocols such as SSH or SFTP. ‘System-Level Auditing Per PABP Requirement 4, logging of critical system activities must be enabled. Oracle eBusiness Suite already provides a set of tools for applications user auditing, described below, To log activities at the operating system-level, various commercial and ‘open-source tools are available, such as snare, Please ensure you configure your system auditing tool to report the following events: + Logon as operating system users, especially for administrative accounts, ‘+ Creation, deletion, or modification of any system-level objects or configuration files, System-level objects are one of the following: + Operating system shared libaries or Windows DLL files, + Operating system configuration files + Operating system executables and system utilities + Oracle Database, Oracle Application Server, or Oracle eBusiness Suite libraries or Windows DLL files, + Oracle Database, Oracle Application Server, or Oracle eBusiness Suite configuration files, + Oracle Database, Oracle Application Server, or Oracle eBusiness executables or system utilities Oracle Database, Oracle Application Server, or Oracle eBusiness Java libary files, Oracle Database, Oracle Application Server, or Oracle eBusiness Suite PL/SQL source files Oracle Database datafiles and redo logs Oracle Wallet directory Configure your system auditing tool to record any changes to these files. Depending on your installation, it may be sufficient to specify only a limited number of top-level directories, for example, the top-level directories for Oracle Database, Oracle iAS, and Oracle eBusiness Suite Oracle Database Ensure that your database installation meets PABP account and password standards as defined in the PABP Requirement 3, Oracle Application Server Enable SSL Oracle Applications provides a web-based interface for all roles and tasks, including administrative ones. Ensure that the Web Services component of the Application Tier is deployed to the SSL-enabled Application Server to protect all administrative access. This is necessary to satisfy the PABP Requirement 13. Application Servers that do not support SSL must not be used in the PABP implementation. Oracle Applications Access Policy Oracle Applications must be configured to conform to the secure account access polices listed this paper. Account Passwords Oracle Applications automatically enforces the following user account password policies through profile options: hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 oneer182017 Document 7383444 Passwords must be a minimum of 7 characters long (profile option, Signon Password Length). Passwords must contain both numeric and alphanumeric characters (profile option, Signon Password Hard To Guess). Passwords expire after 90 days. ‘An account's last 4 passwords must be unique (profile option, Signon Password No Reuse). ‘An account gets disabled after 6 consecutive failed login attempts and remain locked for either 30 minutes or until re- enabled by the administrator (profile option, Signon Password Failure Limit). ‘See section Users Block of the Oracle Application Object Library Security chapter of the Oracle Application System ‘Administrator's Guide — Security document for more information. You can set up more stringent password policies than required by PABP, is it not possible to set more lenient ones. Session Timeout Oracle Application is automatically configured to enforce the following session management policies: + Account session must be inactive after no more than 15 minutes of idle activity This is controlled by the ICX: Session Timeout and ICX: Limit time profile options, See the "User Session Limits” section of the Oracle Application Object Library Security chapter of the Oracle Application System Administrator's Guide - Security document, You can set up more stringent or shorter timeout policy than required by PABP, is it not possible to set a more lenient one, Shared Accounts Shared accounts are not allowed. In particular: 1. Use of group accounts must be disabled. 2. Use of shared passwords must be disabled, User Auditing ‘As per PABP Requirement 4 (listed later in this White Paper), user auditing must be enabled for the following shipped Oracle Applications responsibilities: + System Administrator + System Administration + Funds Capture Setup Administrator ‘+ Funds Disbursement Setup Administrator + Payments Setup Administrator In addition, you must enable auditing for any responsibilities or roles you define which are able to modify system or Payments- related profile options, or any Payments setup entties (of particular importance are formats, system security options, payments systems, payment system profiles, or transmission configurations). The following auditing-related concurrent programs are available to generater reports satisfying the PABP Requirement 4 (described later in this White Paper): Signon Audit Concurrent Requests Signon Audit Forms Signon Audit Responsibilities Signon Audit Users Signon Audit Unsucessful Logins Oracle Applications auditing features and setup are described in the User and Data Auditing chpater of the Oracle Application System Administrator's Guide — Security guide Key Security ‘Access to both the Payments system (key-encryption) key and Payents subkeys (data encryption keys) should be limited to the minimum extent possible using appropriate access control mechanisms. Wallet Access Restrictions (Available only in Oracle Applications Release 12) hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 oneer182017 Document 7383444 Access to the system key's Oracle Wallet file must be limited through operating-systemn account and file-system level restrictions. Copies of the system key wallet file must be kept to a minimum, Access to the wallet is required by each middle- tier web node implementing Payments, If offine transactions are supported or a process payment system integration is implemented, then access to the system key wallet is also required by the concurrent program node implementing Payments. FND Vault Access Restrictions (Available only in Oracle Applications Release 111) FND_VAULT supports the ability to limit access to itself through the implementation of database application contexts, This ensures that only specific database packages have access to the Payment master key stored in the repository. To support PABP Requirement 2.5 (described later in this White Paper), configure FND_VAULT to allow access only by the IBY_SECURITY_PKG package. Secure Network Access Points Payments integrates several of its modules across Tiers and Tier service nodes by network communication. Any of these network links that are over a public network such as the Internet must be secured as part of PABP Requirement 12 (described later in this White Paper). It is recommend that you secure network links that are across private, internal networks as well EC Serviet Deploy the EC Servlet module to a SSL-enabled application server and provide a https:URL for its location in the 1BY_ECAPP_URL profile option. It is necessary to import the public certificate of the hosting application server into an Oracle Wallet that is read-accessible by the database server, Payment System Serviet (Av ble only in Oracle Applications Release 111) ‘SSL-enabled communication between the core Web Services engine and back-end payment system serviets is supported, Deploy payment system serviets on SSL-enabled application servers and provide https:URLs for the serviet location in the “Base URL" field of the payment system definition Payment System Transmission Servlet (Available only in Oracle Applications Release R12) When using the Payments transmission servlet for delegated transmission, provide a https:URL in its transmission configuration setup after deploying it on an SSL-enabled application server. Encryption Modes To ensure compliance with PABP Requirements 1 and 2 (described later in this White Paper), ensure that you have selected Immediate as the encryption mode for credit card data, Data Masking Payments in Oracle Application Release 12 provides complete flexibility in generating masked primary account number values for display in Oracle Applications user interfaces. The PABP Requirement 2.1 allows only the display of the first 6 and last 4 digits of the PAN. By default Oracle Payments ships with a mask setting that displays only the last 4 digits and the PABP patch now enforces the PABP minimums. If your masking policy was less stringent than allowed by PABP, then configure your masking settings accordingly in the Payments Security Options User Interface and run the Credit Card Masking concurrent program immediately to upgrade noncompliant data, Logging Payments logs only masked primary account number values in its debug log files, and never reveals more than 4 digits of the number, regardless of system mask settings. There is no support for logging the entire PAN in diagnostics or logging files. In HTTP name-value pair payment system API (used with the out-of-the-box Cybercash integration), Payments passes request, data, including the PAN, in the HTTP query string of the request. Many application servers by default log the full URL of incoming requests. It is mandatory that you disable request URL logging for each deployed payment servlet container integrating to Payments via its HTTP name-value pair API. hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 seer182017 Document 7383444 To disable request URL logging, edit the httpd.conf file of your Oracle iAS installation. You edit the LogFormat definition containing directives of the form %[a-zA-Z] , Ensure not to include any of the following directives in your LogFormat definition: + 8% + #%q Implementation The following flow is for instrument creation and the registration and persistence of card-holder data such as PAN. The Oracle Payments instrument creation API (implemented as a database-stored procedure) is called by an integrating application, either within the Oracle eBusiness Suite or a legacy application. The request data is sent via a HTTP call-out from the database to a servlet on the middle-tier application server, which retrieves the key-encryption key from a wallet and passes this key and the original request data back to the database and another stored procedure using JDBC. The results of the request are returned to the original stored procedure (Instrument creation API) in the HTTP response. The following flow is for authorization: The authorization API (a database-stored procedure) makes @ HTTP call-out to a servet on the middle-tier application server. The servlet uses the access encryption key from the wallet to decrypt any transaction data, formats it into a payment system native instruction format, and passes the payment instruction to the payment system either directy or through a delivery servlet deployed outside the customer's intranet. If the payment system has a gateway interface (such as, Cybercash or Paypal), then this flow represents settlements and chargebacks as well. For processor interface type payment systems (Paymentech, First Data) the following flow occurs for settlement and chargeback: A scheduled concurrent program runs from a concurrent progressing node and executes Oracle Payments within an embedded JVM. Oracle Payments retrives the access encryption key from the wallet file and passes it to the database using the JDBC to perform bulk decryption of transaction data. The data is returned to the Java layer and formatted into a batch payment instruction file delivered to the payment system either through a direct network connection or through transmitting request to a specialized servlet outside the deployment intranet. Operations Key Rotation According to PCI DSS standard 3.6.4, key rotation must occur at least annually. Key rotation is performed in the Payments Security Options page. Key rotation results in the immediate re-encryption of all data-encryption subkeys with the new system key, Key Wipe In Oracle Payments Release 12 only the administrator provides the location of a new wallet file during key rotation and a new master security key is imported into it either from a pre-generated key in a flatfile or from Payments random key generation program. The following steps must be performed at the end of key rotation to ensure compliance with PABP requirements LL4-1.15: ‘+ IF the new system key was imported from a flatfile, securely wipe the flatfile from the file system. + Securely wipe the old wallet file from the file system; two versions of an Oracle Wallet file exist, a regular version (with * p12 extension) and a single-sign on version (with *.sso extension); be sure to wipe both versions from the file system ‘Secure file system wipe can be performed by several commercial and open-source applications. The following provides a short lst: ‘+ Secure Remove - scrm (open source) + Sdelete Historical Data hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 saneer182017 Document 7383444 As historical transactional data (that is, transactional data that is over a year old) accumulates it should be purged from the system, You can first archive that data to a removable storage device that is then placed in an offline, physically secured location, Purge only the sensitive data and it always resides in the following tables: + TBY_SECURITY_SEGMENTS + IBY_SYS_SECURITY_SUBKEYS After the tables are backed up to an offline storage, run the concurrent programs. Compromised Keys In case of a compromised data-encryption key please do the following + Delete the compromised data-encryption key + Delete all data encrypted by the compromised data-encryption key + Create the deleted functional data ‘The data-encryption key and the encrypted data must be securely deleted as explained in the Historical Data topic, Each row in 1BY_SYS_SECURITY_SEGMENTS is stamped with the identifier of the data-encryption key in column: SEC_SUBKEY_1D. In case of a compromised key-encryption (that is, master or system), do the following: ‘= Unencrypt all PABP data turning off encryption for credit cards; if encryption was enabled for bank accounts disable it + Run the Decrypt Sensitive Data Request Set (IBY_SECURITY_DECRYPT_REQ SET) concurrent program request set and walt for it to complete + Delete all rows in the IBY_SYS_SECURITY_SUBKEYS and IBY_SECURITY_SEGMENTS + Change your wallet and create a new key-eneryption or system key + Run the Encrypt Sensitive Data Request Set (IBY_SECURITY_ENCRYPT_REQ_SET) concurrent program request set and wait for it complete + Securely wipe your old wallet file as per the instruction in described in the Key Wipe topic Password Updates Payment Servlet Cleanup ‘Acknowledgment data can be archived by payment system serviets to prevent data loss to the middle-tier or double-billing of an order. The following pre-Integrated payments systems echo primary account number (PAN) data in their acknowledgment responses: + Paymentech + First Data North Though these acknowledament files are always stored in encrypted format using a data-encryption key provided by the Payments engine, it is necessary to periodically wipe these files with a secure data wipe executable program. See the list of recommended data wipe programs provided in the Key Rotation section. Oracle Payments Release 111 Both the Paymentech and First Data North payment system servlets specify their acknowledgment archive locations using the ARCHIVE_DIR serveet initialization parameter. If both payment systems are implemented, then ensure that both directories are periodically wiped of acknowledgment files. Oracle Payments Release 12 Payments Release 12 uses a single, generic transmission serviet to connect Payments to external payment systems over public networks, The serviet archives payment system acknowledgments in the directory specified by the ARCHIVE_DIR servlet initialization parameter. The contents of this directory must be periodically wiped by a secure data wipe executable. Maintenance hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 saneer182017 Document 7383444 Security Alerts Providing Diagnostic Information If you need to provide log or debugging files to Oracle Support for the resolution of an issue on your installation, then these. files may contain masked or truncated representations of PABP-incidental data. No special procedures are required with respect to transmitting such data to Oracle Support. In the unlikely case that the clear text of PABP-Incidental data Is required to resolve your Issue, follow this procedure to ensure Its secure delivery to Oracle Support Maintenance Security Alerts Pro. 19 Diagnostic Information If you need to provide log or debugging files to Oracle Support for the resolution of an issue on your installation, then these. files may contain masked or truncated representations of PABP-incidental data. No special procedures are required with respect to transmitting such data to Oracle Support. In the unlikely case that the clear text of PABP-incidental data is required to resolve your issue, follow this procedure to ensure its secure delivery to Oracle Support: PABP Requirements Implementation This section lists each of the requirements of the PABP standard and how the Oracle Payments application meets them, Requirement 1: Do not retain full magnetic stripe or CVV2 data PABP 1.1: Do not store sensitive authentication data subsequent to authorization (even if encrypted) PABP 1.1.1: Magnetic Stripe Data Payments does not interface with point-of-sale devices and does not provide the capability to store or process magnetic stripe data. PABP 1.1.2: Card-validation value or code Payments does not store card-validation codes in Oracle Applications Release 111, but simply passes between modules using volatile storage In Oracle Applications Release 12, Payments stores card-validation codes in encrypted format and securely deletes them upon completion of authorization PABP 1.1.3: Personal jentification number (PIN) Payments does not store PIN values and only works with PIN-less debit card payment instruments PABP 1.1.4: Securely delete any magnetic stripe data, card validation values or codes, and PINs or PIN block data stored by previous versions of the software Payments provides upgrade programs to remove such data and replace it, as necessary, with encrypted values. PABP 1.1.5: Securely delete any cryptographic key material or cryptogram stored by previous versions of the software Payments securely removes cryptographic related-material from previous version of the software or provides instructions to the user for using tools to achieve this. PABP 1.2.6: Securely delete any log files, debugging files, and other data sources received from customers for debugging or troubleshooting purposes, to ensure that magnetic stripe data, card validation codes or values, and PINS or PIN block data are not stored on software vendor systems. hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 saneerian017 Document 7383444 Payments only logs sensitive data in an obfuscated format and never in full clear-text. Requirement 2: Protect stored data PABP 2,1: Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be played). ‘Supported through Payments’s credit card masking feature, um, unreadable anywhere it is jed from or stored by wireless networks) by u PABP 2.2: Render PAN, at a mini media, backup media, in logs, and data rec following approaches PAN data is encrypted by Payments using the DES-3 cipher with 156-bit key length, PABP 2.3: If disk encryption is used (rather than file- or column-level database encryption), 1o¢ must be managed independently of native operating system access control mechanisms (e.g. not using local system accounts). Not applicable, PABP 2.4: Application must protect encryption keys used for encryption of cardholder data against disclosure and misuse. Payments meets these PABP requirements PABP 2.5: Application must implement key management processes and procedures for keys used for encryption of cardholder data. Payments meets these PABP requirements within its security architecture described in the overview. Requirement 3: Provide secure password features PABP 3.1: Application must require unique usernames and complex passwords for all administrative access and for all access to cardholder data. Oracle eBusiness Suite supports all PABP password requirements, including requiring complex passwords and enforcing account password changes, PABP 3.2: Access to PCs, servers, and databases with payment applications must require a unique username and complex password. Oracle eBusiness Suite and It technology components support this requirement. PABP 3.3: Encrypt application passwords. Oracle eBusiness Suite supports this requirement, Requirement 4: Log ap} Oracle eBusiness Suite supports this through its user auditing features. Requirement 6: Protect wireless transmissions Oracle eBusiness Suite is neutral with regard to the use of wireless networking technologies. Please be aware that when employing wireless network components your will need to ensure their compliance with PABP Requirement 6. Requirements 8 and 9: Facilitate secure networ! server connected to the Internet implementation / Cardholder data must never be stored on a Payments supports Requirements 8 and 9 through its payment system servlet architecture. hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 ssner182017 Document 7383444 Requirement 12: Encrypt sensitive traffic over public networks Payments meets this requirements through its support of secure transmission protocols such as HTTPS, SFTP, and AS2. Requirement 13: Encrypt all non-console administrative access Oracle eBusiness Suite supports this requirement by allowing a SSL/HTTPS configuration on the Applications Web Services tler. Data Flow The following diagram illustrates the flow of PABP-incidental data between the applications of Oracle eBusiness Suite and within the internal modules of the Oracle Payments application Front End API These APIS provide the PL/SQL interface to Payments payment instrument repository and funds capture payment processing functionality and are the primary interface to Payments for the rest of the Oracle eBusiness Suite, These APIs perform minimal processing and have no persistence to sensitive data, and delegate process execution to the Payments middle-tier Java engine through an HTTP call-out. This module's interaction with PABP-incidental data is as follows: Externally Data Type Received |Stored | Processed | Presented | Transmitted Credit card primary account number (PAN) | _X x (Credit card validation code x x Payment instrument magnetic track data External system access information (for example, login passwords Key encryption cryptographic key Data encryption cryptographic key + Received = The PL/SQL API accepts plain-text primary account number and card security validation code data + Externally Transmitted = This module sends its parameter data to a serviet on the middle-tier for final processing of a request; instructions for securing this network link are given in the Installation section Payment Engine/Back End API The Payments engine receives PABP-incidental data either directly or through its PL/SQL adapter ECServiet interface, and ultimately transmits it to an external payment system for final processing Externally Data Type Received |Stored | Processed | Presented Transmitted Credit card primary account number (PAN) | _X x x Credit card validation code x x x Payment instrument magnetic track data External system access information (2.9 x x x login passwords) Key-encryption cryptographic key x x x Data-encryption cryptographic key x hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 aneer182017 Document 7383444 ‘+ Received indicates that the Engine receives the clear-text of PABP-incidental data either in memory from another co- located eBusiness Suite application or remotely through its EC Application serviet interface. ‘+ Processed indicates that the engine decrypts sensitive data during the process of creating and transmitting payment. instructions. This includes payment instrument data along with remote payment system access information such as account names and passwords. + Externally Transmitted indicates that payment request message contains payment instrument and remote account access data sent either directly to a remote payment system or a Payments back-end payment system servet. Engine PL/SQL The set of PL/SQL methods invoked through JDBC by the Java middle-tier engine to perform both data storage encryption as well as data decryption. Externally Data Type Received | Stored | Processed | Presented | Transmitted Credit card primary account number (PAN) | _X x x (Credit card validation code x x x Payment instrument magnetic track data External system access information (2.9 x x x login passwords) Key encryption cryptographic key x Data encryption cryptographic key x x x ‘+ Received indicates that the Engine PL/SQL accepts plain-text primary account number and card security validation code data as well as remote system access data; it also receives key-encryption (master key) data whenever the master key is created or changed; this data is transmitted through Oracle SQL*Net between the middle-tier to the database host servers. + Stored stores PABP-incidental data in Oracle Applications database tables in both encrypted and digested (hashed) formats, + Processed decrypts PABP-incidental data during generation of payment instruction requests as well as key rotation activities. + Externally Transmitted sends the payment systems servlet module a data encryption key for encryption payment system acknowledgment files; this key is transmitted over HTTP. Payment System Serviet The payment system servlet delivers a funds capture payment instruction to the back-end payment system. This instruction, representing either an authorization or batch of settlements, containa one ore more instances of primary account number and ard validation code data. The interaction is as follow: Externally Data Type Received |Stored | Processed | Presented Transmitted Credit card primary account number (PAN) | _X x x Credit card validation code x x x Payment instrument magnetic track data External system access information (e.9, x x x login passwords) Key encryption cryptographic key Data encryption cryptographic key x hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 ameer182017 Document 7383444 ‘+ Received indicates that the Servlet receives clear-text payment instrument and remote account access data over a HTTP network link as well as a data encryption key to encrypt acknowledgements, + Stored indicates that the Servet archives the payment system response acknowledgment in a local directory to prevent duplicate transactions should the request be retried by the engine after system failure of the initial request; this acknowledgement contains echoed payment instrument data and so is encrypted before being put to file + Externally Transmitted represents the payment instruction data containing primary account number and card validation code data is transmitted to the external payment system. The access credentials to the payment system itself are also transmitted using an insecure protocol (for example, FTP) though typically only over a controlled network link (that is, leased line connection). Scheduler Payments uses the concurrent program processing server to perform both funds capture offline transaction processing as welll as security architecture maintenance routines such as key rotation and historical data upgrade (encryption). Externally Data Type Received | Stored | Processed | Presented | Transmitted Credit card primary account number (PAN) x x Credit card validation code x x Payment instrument magnetic track data External system access information (e.9. x x login passwords) Key-encryption cryptographic key X (Only for R12) Data-eneryption cryptographic key x x + Processed indicates that the concurrent program tier decrypts sensitive data during the process of creating and transmitting payment instructions. It includes payment instrument data along with remote payment system access information such as account names and passwords. + Externally Transmitted indicates that the payment request message containing payment instrument and remote account access data sent either directly to a remote payment system or a Payments back-end payment system servet, ‘Change Record Date Description of Change ‘September 9, 2008 Created document, Oracle Corporation Author and Date ‘Sudha Seshadri and Jonathan Leybovich, September 2008 Copyright Information Copyright © 2004, 2005 Oracle. All rights reserved. Disclaimer This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Software hips:isupor:cace.comlepmesfacesiDocumentDisplay’_ ae. -sato=kuts3eb_S78id= 7389481 aneer182017 Document 7383444 License and Service Agreement, which has been executed and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle without prior written consent of Oracle, This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affliates, This document is for informational purposes only and is intended solely to assist you in planning for the implementation and upgrade of the product features described. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle. Due to the nature of the product architecture, it may not be possible to safely include all features described in this document without risking significant destabilization of the cade. Trademark Information Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates, Other names may be trademarks of their respective owners, Didnt find what you are looking for? hips:isupor:cace.comlepmesfacesiDocumentDisplay’?_ ae. -sato=kuets3eb_S78id= 7383481 sone