Remove Sensitive Data for Auditing
When auditing is enabled in a policy, the request or response message is saved as part of the audit trail. For policies that include auditing, you must ensure that sensitive cardholder data is removed before messages are added to the audit record. PCI DSS specifies what parts of cardholder data must be removed from a message and what parts must be obfuscated. The gateway provides assertions that lets you alter the content of a message. There is also an internal policy that specifically does this for the purposes of auditing.
When auditing is enabled in a policy, the request or response message is saved as part of the audit trail. For policies that include auditing, you must ensure that sensitive cardholder data is removed before messages are added to the audit record. PCI DSS specifies what parts of cardholder data must be removed from a message and what parts must be obfuscated. The
CA API Gatewayprovides assertions that lets you alter the content of a message. There is also an internal policy that specifically does this for the purposes of auditing.
Audit Message Filter Internal Policy
The Audit Message Filter (AMF) internal policy is designed to filter request and response messages, if they are to be included in the audit trail for a particular transaction. The AMF policy can use any of the Gateway assertions to modify the message as required by your organization. The modified version of the message is then be stored in the Gateway database.
To ensure that messages being audited contain no cardholder data, be sure to include the AMF Policy as part of the auditing logic in policies that handle sensitive data. For more information about the AMF policy, see Internal Use Policies.
Constructing an AMF Internal Policy
The AMF internal use policy can include all assertions that are available to regular service policies. These assertions work together to remove sensitive cardholder data from messages before they are audited.
If an incoming message contains cardholder data, the following modifications must be made to the message before storage:
- Remove magnetic strip, card validation code, and PIN data from the message
- Encrypt the Primary Account Number (PAN) using strong encryption
- Optionally encrypt the cardholder name, service code, and expiration date. Provided that the PAN is encrypted, it is not mandatory that this data be encrypted.
The following are some of the assertions that are useful in modifying the message:
Apply XSL Transformation Assertion
If the incoming message is XML, use the Apply XSL Transformation Assertion to either strip cardholder data from the message entirely or replace the contents with other data. This assertion is intended for advanced users familiar with the XSL language and the structure of the XML message being modified.
Evaluate Regular Expression Assertion
The Evaluate Regular Expression Assertion can be used on both XML and non-XML messages to replace data based on regular expression patterns. Use this assertion to replace the CCN with obfuscating characters or remove it entirely from the message. This assertion requires knowledge of regular expressions.
The XML encryption assertions allow the data to be preserved, but protected while persisted to disk by encrypting the contents. For a list of these assertions, see t he "XML Security" section in Product Summary.
Add or Remove XML Element(s)
The Add or Remove XML Element(s) Assertion lets you remove elements from messages based on assignment of elements to variables. Use this assertion to remove cardholder data from standard XML messages.
Sample AMF Policy
The following is a sample AMF policy that makes auditing requests PCI DSS compliant.
In this policy, the request message sent to the Audit Message Filter policy has any sensitive authentication data removed using regular expression pattern matching. The rest of the message is then converted to base64 and XML, and then encrypted to protect the rest of the cardholder data.